The WhatsApp chat export format

Line structure

Every message line begins with a timestamp, followed by the sender name, a colon and a space, then the message body. Anything that does not begin with a parseable timestamp is either a continuation of the previous message or a corrupt line.

The reliable parsing strategy is therefore: try to match a timestamp at the start of the line; if it matches, close the previous message and start a new one; if it does not, append the raw line to the message in progress. Splitting on newlines alone loses every multi-line message.

Timestamp variants we have had to support

This is where most parsers break. The same conversation exported from two phones in different regions produces two different files.

• `[12/03/2024, 21:04:11]` — iOS, bracketed, 24-hour, with seconds.
• `12/03/2024, 21:04 -` — Android, unbracketed, dash separator before the sender.
• `[3/12/24, 9:04:11 PM]` — US locale, month first, 2-digit year, 12-hour.
• `[12/03/2024, 9:04:11 p. m.]` — Spanish locale: lowercase, full stops and a non-breaking space inside the marker.
• `[12/03/2024, 9:04:11 م]` — Arabic locale marker (`ص` for AM, `م` for PM).
• `[12/03/2024, 9:04:11 nachm.]` — German abbreviation form.
• Narrow no-break space (U+202F) before AM/PM instead of a normal space — common on recent iOS builds and invisible in most editors.

Direction and formatting marks

iOS exports prefix each line with a left-to-right mark (U+200E). Arabic, Hebrew and Persian exports additionally contain right-to-left marks (U+200F) and may wrap the timestamp in directional isolates (U+2066–U+2069).

These characters are invisible, so a regex that looks correct in an editor fails against the real file. Strip U+200E, U+200F, U+2066–U+2069 and U+FEFF before matching anything.

System messages

System messages have no `Sender:` segment and are fully translated into the export language. They should be excluded from any style analysis — they are WhatsApp's words, not the participants'.

• Encryption notice: "Messages and calls are end-to-end encrypted…" and its translations.
• Group events: created, added, removed, left, changed subject, changed icon.
• Security-code-changed notices.
• Deleted messages: "This message was deleted" / "You deleted this message".
• Missed voice and video call notices.
• Disappearing-messages state changes.

Media and attachment placeholders

When a chat is exported without media, each attachment becomes a localised placeholder. When exported with media, the line instead references a filename inside the zip.

• `<Media omitted>` (English, Android) and its per-language equivalents.
• `image omitted`, `video omitted`, `audio omitted`, `sticker omitted`, `GIF omitted`, `document omitted` (iOS).
• `<attached: 00000042-PHOTO-2024-03-12-21-04-11.jpg>` when media is included.
• Contact cards, locations and polls each have their own localised rendering.

Other traps worth knowing

• Sender names can contain colons, so split on the first `: ` after the timestamp only.
• A sender name can be a phone number, a saved contact name, or change mid-file when a contact is renamed.
• Group exports contain many senders; one-to-one exports contain exactly two.
• Edited messages append a localised "<This message was edited>" marker.
• Very large exports run to hundreds of thousands of lines; stream rather than loading line-by-line into memory where possible.
• The first line is frequently the encryption notice, not a message — do not assume line 1 identifies a participant.

ZIP layout when media is included

Exporting "with media" produces a flat .zip — there are no folders. iOS names the transcript `_chat.txt`; Android names it after the chat, so the only safe rule is: take the largest `.txt` entry in the archive.

Attachment filenames follow a sequence-prefixed pattern such as `00000042-PHOTO-2024-03-12-21-04-11.jpg`, `00000043-VIDEO-…mp4`, `00000044-AUDIO-…opus`, `STK-20240312-WA0007.webp`. WhatsApp caps a media export at roughly the most recent 10,000 messages, so a media zip is often shorter than the same chat exported without media.

• Entry names in older archives are CP437-encoded unless the UTF-8 flag bit is set; non-Latin filenames arrive mojibake if you ignore the flag.
• Some Android builds nest everything under a single directory named after the chat.
• Attachment references in the transcript are `<attached: filename>` on iOS and `filename (file attached)` on Android.

Encoding

Exports are UTF-8. iOS frequently prepends a UTF-8 BOM (EF BB BF) to the transcript, which becomes an invisible character at the very start of line 1 and breaks a `^\[` anchor on the first message only — a failure mode that looks like an off-by-one bug rather than an encoding bug.

Line endings are LF on Android and CRLF on some iOS/Windows round-trips. Normalise to LF before matching, and never trust a fixed byte offset.

Emoji are ordinary UTF-8, but skin-tone and ZWJ sequences mean one visible emoji can be four or more code points; count graphemes, not code units, in any statistics.

Evidence labels used on this page

WhatsApp publishes no specification for this format. To keep the reference honest, every claim here falls into one of four categories, and we do not blur them.

• **Officially documented** — how to perform the export itself, per WhatsApp's own help pages. That is all WhatsApp documents. Nothing about the file's internal structure is official.
• **Observed in real exports** — everything on this page about line shape, timestamps, placeholders, system-message wording and zip layout. Observed across many devices, locales and app versions, but not guaranteed by WhatsApp and subject to change.
• **Supported by the Neverfar parser** — the variants our open parser handles today, with a test fixture for each: bracketed and unbracketed lines, day-first and month-first dates, 2- and 4-digit years, 24-hour and localised 12-hour clocks, Arabic-Indic digits, bidi marks, multi-line bodies, localised system messages and media placeholders.
• **Known unsupported / edge case** — media zips are read for the transcript only, attachments are not linked back to their messages; poll, location and contact-card payloads are kept as raw text; `<This message was edited>` markers are left in the body; exports where every line is a system message correctly return zero messages.

Test fixtures and parser behaviour

Concrete behaviour is easier to check than prose. The parser drops media placeholders rather than emitting empty messages and reports how many it dropped, so a caller can tell "nothing parsed" apart from "nothing but photos".

The date order is decided once per file, not per line: the whole transcript is scanned for a day value above 12 before any timestamp is converted. Deciding per line produces silently wrong dates in the first two weeks of every month.

Fixtures are synthetic by policy — a real conversation must never end up in a test suite. Each supported locale above has a five-to-fifteen-line fixture covering the platform, phone language and region it represents.

Version and verification

Reference version 1.1 — last verified 12 August 2026 against exports produced by iOS and Android builds current at that date, in English, Spanish, Arabic, German and US-English locales.

Corrections are the most useful contribution. Send a reduced, anonymised sample of any variant that is missing to hello@neverfar.app and it will be added with the next revision.

Why we maintain this

Neverfar reads WhatsApp exports for a living, so this list is drawn from real failures against real files rather than from documentation. The parser behind it is open source and MIT-licensed, so you can use the implementation as well as the description.

Neverfar is a keepsake app that turns an exported WhatsApp chat into a private, text-only AI persona that writes the way that person wrote.