Guide · updated 1 September 2026
Verifying the hash, step by step
Part A of the Schedule requires the hash to be stated. Stating it is only useful if the other side, and the court, can recompute it. Here is exactly how, and what the answer means.
What you need
Two things: the file exactly as it was certified, and the hash value written in Part A. Nothing else — no software to install, no account, no internet connection. Every operating system ships with the tool.
Windows
Open Command Prompt and run:
certutil -hashfile "C:\path\to\WhatsApp Chat.zip" SHA256
It prints a 64-character value. Compare it with the hash in the certificate. Spaces and upper or lower case do not matter; the characters do.
macOS and Linux
shasum -a 256 "/path/to/WhatsApp Chat.zip"
On Linux sha256sum does the same thing. Both print the hash followed by the filename.
Reading the result
- It matches. The file in front of you is byte-for-byte the file that was certified. Nothing has been added, removed or altered since the hash was taken.
- It does not match. The file is not the certified file. That is frequently innocent, and the causes below are worth eliminating before anything is alleged.
Why an honest file stops matching
A hash is exact. Anything that rewrites a single byte changes it completely, and several ordinary handling steps do exactly that:
- The transcript was opened and saved. A text editor may add a byte-order mark or change line endings. Both change the hash without changing a word.
- The archive was unzipped and re-zipped. The files inside are identical; the archive is a different file.
- An email client re-encoded the attachment, or a messaging app recompressed it in transit.
- The file was converted — a transcript pasted into a PDF is a new file, and the certificate’s hash does not describe it.
- The wrong file is being checked. An export taken twice produces two different files, because the timestamps inside the archive differ.
If none of these explains it, the divergence is a matter for evidence, not for a guide.
Getting it right when the record is produced
- Hash the export before anything else touches it — before it is opened, renamed or forwarded.
- State the algorithm alongside the value. “SHA-256” and the 64 characters; a bare value is ambiguous.
- Keep the certified file unmodified, and read from a copy.
- File the file, not a re-saved version of it. If a copy must travel by a route that might re-encode it, send it inside an archive.
- Print the verification commands on the document itself, so the other side can check without asking you how.
Every exhibit Section63 issues carries the hash on its cover with the certutil and shasum commands printed beside it, precisely so verification does not depend on us.
This guide explains procedure and states the law as we understand it. It is not legal advice, and Aarohan Enterprises is not a law firm. Whether a court admits a particular record, and what weight it gives it, is for that court to decide. Have an advocate settle anything you intend to file.
Prepare one now
Section63 builds this document from your export.
Drop in the .txt or .zip WhatsApp gives you and read the whole
exhibit — transcript, Part A, Part B, Schedules and the integrity checks — before you pay.
More guides