How the export is made

This page describes how ChatExport produces a document and what each part of it will support. The second half is the more useful one: what the program cannot recover, and what is left in the record when it cannot. A document is worth more when its limits are stated on it than when the other side finds them.

There are two sources, and they are not equally strong. An iPhone backup is a database Apple's own software wrote. A WhatsApp export is a transcript WhatsApp produced when somebody asked it to. Everything below applies to the backup unless it says otherwise, and the section on WhatsApp exports sets out exactly where the two differ.

Where the text comes from

The messages are read out of the Messages database that Apple's own software wrote into the backup on your PC. Nothing is retyped, photographed, or read back from an image of a screen.

ChatExport finds that database inside the backup by its fixed path, HomeDomain/Library/SMS/sms.db, in every backup layout Apple has used.
The database's write-ahead log, sms.db-wal, is copied out with it and applied to the copy, never inside your backup. Skipping that step is how the most recent messages go quietly missing from an export.
The backup itself is never written to. ChatExport opens it read-only and works on its own copy in a temporary folder, so reading a backup leaves it byte for byte as Apple's software wrote it, with nothing added to its folder, not even scratch files.
The layout of that database changed several times between iOS releases. The program detects which layout it is looking at and adapts, which is why a backup from a phone you no longer own still opens. iOS 11 up to the current release.
Timestamps, delivery and read times, reactions, replies, edits and attachment records all come out of the same rows as the text. They are read, not inferred.

When the source is a WhatsApp export instead

The second source is the file WhatsApp writes when you choose Export chat, either a .zip with the media beside the transcript or a bare .txt without them. It is read by the same program into the same document, but it is a weaker kind of evidence than a backup, and the document says so instead of presenting the two alike.

The document names its source. Every export made from a WhatsApp file carries two extra rows in its header: the name of that file, and its SHA256. A document made from an iPhone backup does the same thing one level down: its Document Integrity page lists the SHA-256 of the message database exactly as the backup stores it, so either kind of document can be traced to the file it was read from.
Two hashes, two different claims. The SHA256 described in the next section covers the file ChatExport wrote and says it has not changed since. The source hash covers the file WhatsApp wrote and says this document was made from that file and no other. Keep the export file exactly as WhatsApp saved it, the same way you would keep a backup folder.
The file carries no time zone. Its clock times are read in the time zone of the computer running the import. The import screen states that before you export anything and the title page names the zone. If the conversation happened somewhere else, the printed times are this computer's, not the phone's.
The file does not say who exported it. Both sides look alike in a transcript, so ChatExport asks which participant is you, and nothing continues until you answer. Guessing from who wrote most, or who wrote first, would be wrong often enough to be unusable in evidence.
Lines about the group itself are left out and counted. Somebody joining, a name change, a missed call, the encryption notice: these carry a time but no sender. They are skipped, the number of them is counted, and the import screen shows that number. Dropping them silently would hide part of the file from the person relying on it.

How the date order is decided

A WhatsApp export records nothing about the phone that made it, so "03.04.2026" is the third of April or the fourth of March depending on that phone's settings, and reading it the wrong way moves every date in the document. The decision is made once, across every timestamp in the file at the same time, and the import screen shows both the decision and what settled it.

What decides it	What the screen says
A full year written first, as in 2026-04-03	Certain. The file writes full years first.
Any component above 12, anywhere in the file	Certain. A date in the file settles it.
The order of the file itself. An export is written oldest message first, so only one reading of the dates runs forwards in time	Certain. Only this reading runs forwards in time.
None of the above, which happens when the conversation fits inside a single month	Assumed, day before month. Nothing in the file decides it.

The last row is why the rest of it exists. An interpretation nobody can check has no business in a document going in front of a court, so the difference between "we read this out of the file" and "we assumed it" is on screen before you export, in those words.

What the SHA256 covers

When the document is finished and written to disk, the program reads that file back and computes a SHA256 hash of it, byte for byte. Every format gets one, not only PDF: a CSV handed to a lawyer deserves the same treatment.

The hash appears on the final screen, with a button to copy it.
It is also written beside the export as <file>.sha256, in the format that certutil -hashfile on Windows and sha256sum -c elsewhere already understand. Anyone can re-check the file later without this program.
It covers the whole file. Alter one character anywhere in it and the hash no longer matches.

So it proves one thing: this file is the file that came out of the export. It proves nothing about what happened on the phone. It is a seal on a document, not a witness to a conversation.

Because the hash is computed after the document is complete, it cannot be printed inside the document it describes. That is why it is on the screen and in the small file next to the export, and why it is worth recording at the moment you file.

A second export will not have the same hash, and that is correct

Export the same conversation from the same backup twice and the two files will not share a fingerprint. Each title page records the moment that document was made, so the two differ in that line, and one differing character is enough to change the whole hash.

This is not a defect. The hash was never an identifier for a conversation. It identifies one file. What makes a second export worth something is that it reads the same, from the same backup, which is the reason to keep the backup folder alongside the document rather than to expect two exports to match.

A second hash points back at the backup

The hash above answers one question, whether the file changed after it was written. The Document Integrity page answers the other one, where it came from: it lists the SHA-256 of the message database exactly as the backup stores it, and lists the write-ahead log separately when the backup held one that was not yet merged, next to the device name, the iOS version and the backup date.

Anyone holding the same backup can recompute those digests and confirm the document was produced from those files, without this program. Because the files are hashed as the backup stores them, the numbers from an encrypted backup can be reproduced without knowing its password. The page also states, in the document itself, that the backup was opened read-only and not modified.

Time zones

The database stores each message as an instant, counted from 2001, with no time zone attached to it. The program converts every one of them to the local time of the computer running the export, and the title page names that zone once, in the form Europe/Warsaw (UTC+02:00). The message lines then carry clock times without repeating the offset on every row.

Two things follow, and both are better known in advance than raised by someone else.

Export the same conversation on two computers set to different time zones and the printed times differ. A message sent close to midnight can appear under a different date heading, because the day separators are drawn from the same local time as the times themselves.
The order never changes. Messages are read in the order of the stored instant, so no time zone setting can reorder a thread.

The CSV export keeps the full offset on every single timestamp. That is the one to use when a conversation crosses a daylight saving change and the exact minute is the point in dispute.

The title page also records when the export itself was run, to the minute, in the same zone.

Where the message numbers come from

With message numbering on, every message in the document carries a number, #1 to #N, in the order they were sent. Court View turns it on by itself, along with the rest of the verifiable detail. Chat View leaves it off unless you ask for it.

The numbering runs across the whole document rather than restarting per page. #143 means the same message on page 2 and on page 40.
A reply prints the number of the message it answers, "In reply to #87", whenever that message is inside the same export.
Court View prints the number in the transcript row. Chat View hangs it in the margin beside the bubble, so the conversation itself is left exactly as it renders.

One limit decides how a number should be quoted. The number is a position in this document, not an identifier the phone carries. Export a narrower date range and the same message gets a different number. A citation is therefore unambiguous against a named file, which is the second reason to record its hash: "message #47 of the export whose SHA256 begins 3f9a" points at exactly one thing.

Names, and the numbers behind them

Contact names come from the address book inside the backup itself, the AddressBook.sqlitedb that Apple writes into every backup. The handle on a message is matched against it and the document prints the name.

A name on a phone is whatever its owner typed. The number or email address is the part a reader can check against something else, so the title page always lists participants with the raw handle next to the name, in both Chat View and Court View.
Court View prints the handle next to the name on every message as well. Chat View does not, unless you switch it on.
When no contact matches, the raw number or email is printed. No name is invented, and a backup with no readable address book simply shows handles throughout.
The database cannot say which number belongs to the phone's owner, because outgoing messages carry no handle at all. That number is read from the backup's own Info.plist, or you type it in. When neither supplies it, the title page names the owner without a number rather than guessing one.

What cannot be recovered

Recovery has hard limits. Here they are, with what survives in each case, because "the words are gone but the record that something was sent and withdrawn is not" is the difference between a document that holds and one that does not.

The situation	What is left in the document
A message deleted from the phone within roughly the last 30 days, on iOS 16 or later	Recoverable. iOS moves it to a Recently Deleted store instead of erasing it, and that store is in the backup. The switch is off by default, because these messages are not in the thread as the phone shows it today. Switched on, they appear in place, marked with the date they were deleted where iOS recorded one, and counted separately on the title page.
A message already gone from the phone when the backup was made, and older than that window, or deleted on an iOS with no Recently Deleted store	Nothing. It is not in the database, so it is not in the backup, and no software reads what is not there. The document shows no gap either, because there is nothing left to mark.
The text of a message the sender unsent	The words are gone from both phones and nobody can recover them. The record that a message was sent at that minute and then withdrawn survives. The document keeps the line and says so, rather than closing the gap as though nothing had been there.
An earlier wording of an edited message that iOS did not keep	Where iOS stored prior versions, "show edit history" prints each one under the current wording with the time it was replaced. Where it stored none, the document can say only that the message was edited.
A conversation that exists only in iCloud, with no local backup on this PC	Nothing to read. The program reads a backup folder on your own disk and never signs in anywhere. Make a local backup with Apple's software and everything in it becomes readable.
Older messages the backup never held, because Messages in iCloud kept them in the cloud or Keep Messages was set to 30 Days or 1 Year	Nothing, and this is the gap that leaves no trace at all: the conversation simply starts later than you remember it starting, and nothing in the transcript says why. Both settings are read out of the backup rather than guessed, and the export screen says so before you export anything. When both ends of the covered span are known, the screen shows those dates too, so you can check them against your own memory; half a range is never shown, because it would invite the wrong conclusion about the other half. On an ordinary backup nothing appears.
An attachment the backup does not contain	The file name, printed and labelled as a missing file. Nothing is substituted and no placeholder is dressed up as the picture.
Video and voice messages, as playable media	Listed where they were sent, with file name, size and time, and collected in an index at the end of the document if you ask for one. A PDF cannot play a video, and pretending otherwise would make the document look more complete than it is.
The time a WhatsApp message was edited or deleted	The export records that it happened, never when. Both are marked in the document and the time is left blank rather than filled in with the send time, which would print an edit time nobody ever recorded. A deletion notice becomes a withdrawn message with no text, so it reads as a withdrawal instead of as words the sender typed.
Delivery and read receipts, reactions and reply threading in a WhatsApp conversation	Nothing. WhatsApp does not write them into the export file, so those parts of the document are absent rather than empty. All of them are present for iPhone Messages, where the database records them.
Messenger, Signal, Telegram and every other app	Not read at all. The two sources are the iPhone Messages database (SMS, MMS, RCS and iMessage) and WhatsApp's own export file. Everything else keeps its history in its own format, and doing one of them properly is its own piece of work.

The two recovery switches, deleted messages and edit history, are off by default in both PDF styles. They change which messages the document contains rather than how much each one shows, and turning them on silently would misrepresent the thread against the phone it came from.

What language the document is written in

Whichever of fourteen you choose, and it is a separate choice from the language of the program: English, Polish, German, French, Spanish, Italian, Dutch, Portuguese in both its Brazilian and its European form, Czech, Romanian, Swedish, Ukrainian and Russian. You can work in English and produce a document for a court that reads none.

The messages themselves are never translated. They are reproduced exactly as they were sent, in whatever language the two people were writing in. An export whose evidence had been through a translation engine would be a different document from the one on the phone, and this program does not produce one.
What the choice covers is the frame. The title page, the integrity statement, the description of what was exported and what was left out, the statistics, the labels beside each detail, and the way dates and times are written. Each language was written for the whole of that, which is why the list is fourteen rather than fifty: a language appears on it only once nothing in the frame is left in another one.

What Court View switches on

Choosing Court View turns on every detail the backup already holds: full timestamps with seconds, the date on every message instead of only the first of the day, sender numbers beside names, delivery and read times where the backup recorded them, message numbering, and the original file name and size captioned under each photo. Chat View leaves them off, because a document meant to be read is not the same document as one meant to be checked. Neither style changes a single message.

What this page is not

This describes what the software does. It is not a promise about admissibility. ChatExport reproduces what is in the backup; whether a particular document is accepted in a particular case depends on the jurisdiction, the case and the judge. That is the second question, and a lawyer answers it, not a program.

Contact

If something here is not specific enough to answer your question, ask: support@getchatexport.com.