Screenshots, OCR or a database read: three grades of message record

Three people can capture the same conversation three different ways and end up with three records that are not interchangeable. What separates them is how much of the conversation is still data once the capture is done, and it decides what questions the record can answer later.

This page is about one kind of conversation: iPhone Messages (iMessage, SMS and RCS) as stored in an iPhone backup on a Windows PC, which is where ChatExport reads it. The program’s other source, a WhatsApp chat export file, holds much less: WhatsApp does not write delivery and read receipts, reactions or reply threading into that file, so most of the field list below does not apply to it. What a WhatsApp export file leaves out is set out on the methodology page.

What is the difference between a screenshot, an OCR transcript and a database export?

	What it is	What survives	What is lost
Screenshot	A picture of the screen	What was on screen at that moment, laid out as the phone drew it	Everything outside the frame
OCR transcript	Software reading that picture back into text	Searchable text	Any character the reading got wrong, plus everything the screenshot already lacked
Database read	The message records in the phone’s database, as copied into the backup	Fields per message: sender, timestamp, delivery and read times, reactions, replies, edits, attachment records	Whatever the phone no longer held when the backup was made

A buyer comparing feature lists is often comparing different kinds of thing under one heading, which is why the comparison of apps that print iPhone text messages for court sorts them first by where the text comes from.

Having screenshots closes nothing. As long as the phone, or a backup of it, still holds the messages, a database read can be made later from the same conversation.

What does a screenshot actually lose?

Everything outside the frame of the screen at the moment it was taken, which is more than it looks like, because what a screenshot does keep is so convincing.

A screenshot holds the stretch of the conversation that was on screen, drawn the way the phone drew it at that moment. A long argument captured in a hundred screenshots is a hundred fragments, and nothing in them shows what sat between two of them, or that none was left out.

Is a screenshot worthless then?

No. A screenshot is immediate, anyone can make one, and for many purposes it is entirely sufficient. What it is not is a complete record of the conversation, and the gap only matters when somebody disputes what is not in the frame.

Why is OCR a step down rather than a step up?

Because it adds a reading step on top of a record that has already lost everything outside the frame. Software reading letters off a picture can misread them, a 1 for an l or one digit of a time for another, and a plain-text transcript does not mark which characters were read correctly.

ChatExport uses no OCR at any point. It reads the database, so there is no picture of a screen in the path to transcribe. The Document Integrity page of a PDF made from an iPhone backup states it in this sentence: “No Optical Character Recognition (OCR) was used: text was read from the database, not from screenshots or images.”

What does a database read hold that a screenshot does not?

Fields rather than pixels, for the whole conversation rather than the stretch somebody scrolled to:

• Its own timestamp on every message, as the phone stored it.
• Delivery and read times per message, where the phone recorded them, with the asymmetry intact. On a message you sent, a read time can only exist if the other person’s phone sent a read receipt, and Apple’s Messages guide for Mac, on read receipts says nobody can turn them on for anyone but themselves. So a sent message with no read time is not evidence that it went unread. On a received message, the read time is when the phone’s owner opened it, and the PDF says that in a note.
• Which service carried each message, iMessage, SMS or RCS, where the backup records it.
• Reactions and replies, and edits and unsent messages as marks of their own, with the earlier wording of an edit where the database kept it.
• Messages deleted on the phone that are still in its Recently Deleted store, which Apple keeps for 30 to 40 days on iOS 16 or later, so a backup made today does not hold a message deleted longer ago than that. ChatExport includes these only when you turn that option on, and marks each one as deleted.
• Attachments as records: file name, type and size from the database row. When the file itself is not in the backup, an English-language PDF prints “missing file” beside its name rather than leaving a gap.

A database read is not complete by definition either. What the phone no longer held on the day of the backup is not in it, and no reading of the backup brings it back.

What does the document itself say about where it came from?

A PDF made by ChatExport 1.0.0 from an iPhone backup has a Document Integrity page naming the device, the iOS version, the date of the backup and whether that backup was encrypted, followed by the SHA256 of the message database. That number is computed over the file exactly as it is stored inside the backup, which for an encrypted backup means the encrypted bytes, so anyone holding the same backup can recompute it without the password and see whether the document was made from that file. The write-ahead log gets its own line when the backup held one. Beside the numbers sits a note, the program’s own statement about how it opened the backup: read-only, and not modified.

Two further things travel with the file. After every export, in any of the five formats (PDF, TXT, HTML, CSV and RSMF), the program writes a file of the same name with .sha256 added, holding a line with the hash, two spaces and the file name, which is the line format that sha256sum -c checks. On Windows, certutil -hashfile computes and displays the hash of a file, and you compare it with that line yourself. And every page of the PDF after the cover carries, in its footer, the address of a page on this site where a recipient can check the hash: it computes SHA256 in their own browser and uploads nothing.

Does a hash make a document admissible?

No. A hash shows that a file has not changed since it was written. It compares bytes, not intentions: it does not say who wrote the messages, whether the conversation is genuine, whether the backup behind it was complete, or whether any particular court, tribunal or employer will accept it. What a court accepts is decided by that court, and nothing on this page is legal advice. What the hash does give anyone holding the file is a way to check, with a tool already on their computer, that the copy in front of them is byte for byte the file that was exported.

The full guide to exporting iPhone messages for court covers the whole route from the phone to the document.