The other side will not hand over the phone. They do not have to.
Ask them to export the conversation themselves. It is four screens on their own computer, with
no lab, no device to surrender and nothing sent anywhere. What arrives is a PDF
and a second, much smaller file ending in .sha256: the fingerprint of the document,
taken as it was written. Change one character in that document afterwards and the fingerprint
stops matching.
Every export also states what it leaves out: how many messages a date filter removed, how many attachments were never in the backup, and which phrases were hidden at whose request. A document that hides its own gaps is worth less than none.
You verify it without us
The checksum is an ordinary SHA256, written in the format certutil and
sha256sum already read, and it lands beside every export with no switch to turn it
off. On Windows, in the folder holding the document:
certutil -hashfile "conversation.pdf" SHA256 On a Mac:
shasum -a 256 conversation.pdf
Compare the 64 characters it prints against the contents of the .sha256 file. No
account, no upload, and not even our program: software your office already has settles it. For
whoever receives a document from your client there is
a page that explains this check in full, written for a
reader who has never heard of us.
The document names its own source
A checksum answers one question, whether this file changed since it was made. It says nothing about where the file came from. That is the other direction, and the document answers it on its own integrity page: the device, the iOS version, the date of the backup, whether that backup was encrypted, and the SHA256 of the message database files as they are stored inside the backup.
Two consequences worth having. Anyone holding the same backup can recompute those digests and see that the document was produced from those files rather than from something else. And because the digest is of the stored bytes, an encrypted backup can be checked by a third party without the password and without trusting our decryption. The page also records that the backup was opened read-only and not modified, which is the thing a careful opponent asks about next.
It states its own gaps
The same page carries the scope of the export: whether the document holds every message of the conversation, or a number out of a larger number, and then, line by line, what is missing. Messages outside the date range. Automated carrier notices skipped, the missed-call texts a network injects into a thread. Messages hidden because the exporter typed a phrase, with those phrases printed in full, so the reader can weigh the omission instead of never learning of it. Photos or other attachments excluded. Recovered deletions included and marked as such.
In Court View the hiding option is switched off outright, rather than merely left empty. The one document where "trust me, nothing important was removed" is unacceptable is the one that goes into a bundle, so an export in that theme has no mechanism for quietly dropping a message on the strength of a word.
Citing one message out of forty thousand
Court View is the plain layout: monochrome, formal header, no coloured bubbles. Choosing it also turns on the detail a record needs, rather than leaving each switch to be remembered. Full timestamps with seconds and the time zone. The sender's number or address beside the contact name, because a name in an address book is editable and the handle is the identifier. Delivery and read times where the backup recorded them. Sequential numbering, #1 to #N across the whole document rather than restarting on each page, so a reply prints as a reply to #143 and a submission can cite that number instead of a page and a paragraph.
An edited message prints the wording it had before, with the time of the edit, when the export is made with edit history on. A message the sender unsent leaves the record that something was sent at that minute and then withdrawn: the words are gone from both phones and nobody can recover them, and the document says exactly that rather than skipping the line.
RSMF, when the destination is a review platform
One of the five export formats is RSMF (Relativity Short Message Format): the conversation lands in an eDiscovery platform as records with participants, timestamps and attachments, instead of as a PDF somebody has to re-key. It sits in the same one-time licence as everything else.
The honest limit on that sentence: the output was validated against the format's own schema and a validator sample, not against every importer that claims to read it. If your platform is the deciding factor, export one conversation on the trial and load it before you buy anything.
What this does not do, asked or not
- It does not make anything admissible. That is the court's decision, taken on the whole chain: where the phone came from, who secured it, how the backup was made, and whether the evidence was lawfully obtained. What software can do is make authentication cheap and then describe itself precisely. In US practice a digest of this kind is what Federal Rule of Evidence 902(14) contemplates, but ChatExport does not write the certification itself: that document is yours, and nothing on this site is legal advice.
- A matching checksum proves bytes, not truthfulness. It shows the file has not changed since its fingerprint was recorded. It says nothing about who wrote the messages inside, and somebody who fabricated a conversation before exporting it gets a matching checksum too. That is correct behaviour, and the app says the same on its own verify screen.
- Our chain starts at the backup. What happened to the phone before that is outside anything an export can speak to, and an investigation that needs an image of the device itself is a different job for a different examiner.
- Deleted messages come back only from roughly the last 30 days. That is the window iOS 16 and later keep, they are exported labelled with the date of deletion, and anything older is genuinely gone from the phone.
- A WhatsApp chat is one step further from the phone. There the source is the file WhatsApp writes on request rather than a database lifted off the device, and it carries no time zone, no delivery or read receipts, no reactions and no reply threading. The document names that file and prints its SHA256 rather than implying a phone was read. The methodology page sets out both sources in detail.
- For filing, prefer the PDF. An HTML export is a document plus a folder of media beside it, and the checksum covers the file it names. One PDF is one file, one fingerprint and one thing to lodge.
What to ask your client to do
- Back the iPhone up to their own PC with Apple's own software, the Apple Devices app or iTunes. An encrypted backup is fine: ChatExport asks for that password and reads it normally.
- Install ChatExport, open the backup, and take the conversation whole rather than a date range. A range that begins the day before the useful message invites the question of what is missing.
- Choose PDF and Court View, and leave photos and attachments in.
-
Send you both files, the document and the
.sha256beside it, and ask for the checksum in the covering message as well. A value given before anybody asked questions is worth more than the file itself. - Ask them to keep the backup folder untouched. It is what an expert would be pointed at if authenticity is contested, and a second export from it reads the same. That new file will carry a different SHA256, because every export stamps its own date and export ID: the hash proves one file is unaltered, never that two exports are byte-identical.
Look at one before you recommend it
Open a sample Court View export, produced by the program rather than drawn for this page, with an edited message printed above the wording it replaced. The trial is the whole program, watermarked and stopping at the 50 most recent messages, and it does not expire, so a real conversation can be tested before anybody pays.
A question about a matter in front of you is better answered by mail than by a page: support@getchatexport.com reaches me directly.