File checksum terms
A file checksum is a short fingerprint worked out from every byte of a file, so if the logo pack your client approved has the SHA-256 that starts ba7816bf (example), any later copy with the same fingerprint is exactly that file, and a copy with even one changed pixel gets a completely different one.
On client projects the question is rarely “is this file corrupt?” and usually “is this the file they said yes to?”. These are the words you meet when you answer it with a checksum.
- Checksum or hash
- A fixed-length string of letters and digits made from the contents of a file. The same bytes always give the same checksum; different bytes, even one, give a different one. The file name and date play no part.
- SHA-256
- The checksum to use by default. It is 64 characters long and is the standard for proving that two files are identical. Use it in approval records and handover notes.
- SHA-1 and SHA-512
- Older and longer relatives of SHA-256. SHA-1 is still printed by many download pages and backup tools; SHA-512 is shown for completeness. Use whichever the other person sent you.
- MD5
- A short, 32-character checksum that is still common on download pages and in asset libraries. Fine for spotting an accidental change, but it can be faked on purpose, so do not rely on it alone as proof.
- Expected checksum
- The checksum someone gave you for a file: on a download page, in a handover email or in your own sign-off record. Paste it into the check box and the tool tells you which kind it is and whether your file matches.
- Approval record
- A short block with the file name, exact size, checksums and the date. Paste it into the email where the client approves, and the approval is tied to one exact file rather than to a name like “final-v3-FINAL.pdf”.
How a file checksum reacts to one-character edits
These rows hash short made-up texts, standing in for files, so you can see real checksums. Each one runs through the same MD5 and SHA-256 code the tool uses. Notice how one extra space or one lower-case letter changes the whole checksum.
| Example | Size | MD5 | SHA-256 | Same as the approval note? |
|---|---|---|---|---|
| Example: an empty file | 0 bytes | d41d8cd98f00…427e | e3b0c44298fc…b855 | No |
| Example: approval note | 20 bytes | 43fd6dc7b9a0…7991 | aeb36641bfc7…a560 | Yes |
| Example: same note, one space added | 21 bytes | ec45549d5230…3331 | 6330feff6d57…a5ae | No |
| Example: same note, lower-case h | 20 bytes | 4e564279acd5…94b9 | 6678d0168bdd…619e | No |
| Example: the approval note again | 20 bytes | 43fd6dc7b9a0…7991 | aeb36641bfc7…a560 | Yes |
| Example: the classic test text | 3 bytes | 900150983cd2…7f72 | ba7816bf8f01…15ad | No |
What a file checksum cannot prove
A file checksum proves sameness, not who approved it
Matching checksums tell you two files are byte-for-byte identical. They do not show who approved the file or when. Keep the checksum next to the approval itself: in the client’s reply email, a signed sign-off form, or a review tool that records each approval.
Re-saving a file changes its checksum
Opening an image or PDF and saving it again, exporting twice, or zipping it on another computer usually changes the bytes even when nothing looks different. Hash the exact file you send, and send that same file, rather than a fresh export of it.
Some messaging apps change files in transit
Chat apps and email clients often compress images and videos, or strip their metadata. If the client’s copy has a different checksum, ask them to send the file back as a document or download it from the original link, then check again.
Very large files need memory
The tool reads the whole file into your browser to hash it, up to 1 GB. On a phone, very large videos can run out of memory. For big renders, hash them on a computer, or hash the zipped delivery instead.
Questions about file checksums
Is my file uploaded when I make a file checksum here?
No. The file is read by your browser and hashed on your device; nothing is sent to a server. You can disconnect from the internet after the page loads and it still works, which makes it safe for unreleased client work.
Which file checksum should I use, SHA-256 or MD5?
Use SHA-256 for your own records and anything you might need to rely on later. Use MD5 or SHA-1 only when someone else gave you one of those to check against, for example a download page or an older asset library.
How do I check a file against a checksum someone sent me?
Add the file, then paste the checksum into “Check against a checksum”. You can paste a bare checksum, one in capitals, or a whole line such as “SHA256 (logo.zip) = …”. The tool works out the type from its length and shows a clear match or no match.
Can a file checksum show what changed between two versions?
No. It only says same or different. To see what changed, compare the two images with the image comparison tool, two PDFs with the PDF comparison tool, or pasted text with the diff checker.
Why did the file checksum change when the file looks the same?
Something in the bytes changed: a re-export, a new embedded date, removed metadata, or compression by a chat app. The checksum is strict on purpose. If you need to know whether the visible content changed, compare the files visually instead.
Does renaming a file change its file checksum?
No. The name, folder and dates are not part of the contents, so “logo-final.png” and “logo-approved.png” have the same checksum if the bytes are the same. That is why a checksum is better proof than a file name.
Where should I keep the file checksum after the client approves?
Next to the approval. Paste the approval record into the email thread, add it to your sign-off form, or keep it in the project notes with the date. When someone later asks which version was signed off, you can hash the file in question and compare.