Hash Report Generator
Turn a set of checksums into a verification certificate you can file, send or archive.
What this does
Most hash tools give you a string to copy. This one also produces a document: hash any number of files at once, then export a timestamped report listing every file, its size, its algorithm and its digest, under a unique report ID. Attach it to an audit, a handover, a legal bundle or a change record.
[1] SELECT FILE(S) TO HASH
One file, several, or two to compare.
[2] CHOOSE YOUR HASH FUNCTION
What the report contains, and why
A digest on its own proves very little. "This file's SHA-256 is 3a7b…" raises the obvious questions: which file, checked when, by whom, and with what? The report is the digest plus the context that lets someone else rely on it months later, when you are not there to explain it.
| Field | Why it is there |
|---|---|
| Report ID | Lets a ticket, case file or audit control point at this exact document. |
| Timestamp and time zone | Places the check on the timeline of events. The time comes from your computer's clock, so check it is right before you start. |
| File name, path and size | Says which artefact each line is about. When you hash a folder, the path inside the folder is kept, so two files called IMG_0001.jpg in different sub-folders stay distinguishable. |
| Algorithm | A bare hexadecimal string is not self-describing. Naming the algorithm on every entry lets anyone recompute it, and shows whether it is still considered strong. |
| Digest | The value that a later check is compared against. |
| Success and error count | Makes a partial run visible. A file that could not be read appears as an error instead of silently disappearing from the list. |
| Title, purpose, operator, organisation | Optional, but the purpose is usually the first thing an auditor asks about, and the operator is the person who can later confirm the check. An optional evidence section in the report form adds a case reference, source device, place and a signature block. |
How to generate one
- Select every file that belongs in the report. You can pick many at once.
- Choose an algorithm. SHA-256 is the right default for anything that must hold up to scrutiny.
- Press [CALCULATE HASH] and let every file finish.
- Press [GENERATE REPORT], fill in the title, purpose and operator fields.
- Pick a format and download. The file is produced in your browser.
Available formats
| Format | Best for |
|---|---|
| Filing, printing, attaching to an audit or legal bundle | |
| CSV | Loading the digests into a spreadsheet or asset register |
| JSON | Feeding another system or a verification script |
| HTML | Sharing a readable report by email or intranet |
| TXT | Plain records, diffing, appending to a log |
Who uses this
Evidence and handover
Record the state of a set of files at a moment in time, before they move between parties, so any later change is demonstrable.
Audit and compliance
Attach a checksum manifest to a control, showing which artefacts were reviewed and exactly which versions.
Release engineering
Publish a manifest alongside a build so downstream consumers can confirm they received the same artefacts.
Archival
Store digests next to long-term backups so silent corruption can be detected years later.
A procedure that holds up in an audit
The tool produces the document; the procedure around it is what gives the document weight. This is a workable routine for handovers, audits and internal chain-of-custody records:
- Hash before anything moves. Take the digests before the files are copied, sent or handed over, not after. A value taken once a file has passed through three systems documents its current state, not the original one.
- Hash the whole set in one run. One run gives one timestamp and one report ID for the batch, which is easier to reference than a pile of separate checks.
- Fill in purpose and operator straight away. "Pre-release check of build 4.2 by J. Smith" is easy to write today and impossible to reconstruct in a year.
- Store the report away from the files. Anyone who can change the files and the report together can make them agree. A ticket system, a document management system or an e-mail to a third party keeps it out of reach.
- Recompute on receipt. Whoever receives the files hashes them again, with the same algorithm, and compares the values line by line. The compare page does this per file: paste the expected value and it shows a match or a mismatch.
- Keep both reports. The pair, sender's and receiver's, is the record that nothing changed in between. Either one alone only describes one end.
Use SHA-256, and say so
For a record that may be questioned, use SHA-256. Researchers have shown that two different files with the same MD5 can be produced on an ordinary computer, and a SHA-1 collision was demonstrated publicly in 2017. A report built on either cannot rule out that someone prepared a second file with a matching digest. If you are re-checking files against an old MD5 list, record both: the MD5 for continuity with the old record and a fresh SHA-256 from now on. The "MD5 + SHA-256" option computes both in a single read of each file. The algorithm guide covers the trade-offs in more detail.
What weakens a report
- ×Keeping it next to the files, in the same folder or on the same drive.
- ×Copying the digests by hand. One mistyped character turns a match into a mismatch. Export the report rather than retyping values.
- ×Hiding failures. A report that quietly covers 9 of 10 files is worse than none, because readers assume it is complete. Re-run the failed files or say why they are missing.
- ×Reading it as proof of origin. A hash shows that a file has not changed since it was hashed. It says nothing about who created the file or whether its content is genuine.
What the report is not
It is a record you made yourself. It is not notarised, not witnessed, and its timestamp is not issued by a trusted third party. For most audits, handovers and internal controls that is what is expected. Where a stronger form is required, such as a qualified timestamp, an electronic signature or a certificate in a prescribed legal format, the report is an input to that process, not a replacement for it. Ask whoever owns the process what they accept before relying on it. For the certificate that Indian courts ask for with electronic evidence, see the hash value certificate page.
Your files stay on your machine
Hashing and report generation both run entirely in your browser. No file, digest or report field is transmitted anywhere. That is what makes this usable for confidential material, and it also means the report is produced offline once the page has loaded.
FAQ
Is a hash report legally valid evidence?
It shows that each file matched its digest when you ran the check, which is what most chain-of-custody processes need. How much weight it carries depends on the jurisdiction and on the process around it; see what the report is not above.
How many files can one report cover?
There is no fixed limit. Select as many files as you need in one go; each appears as its own row with its own digest, and the report records how many succeeded and how many failed.
Which algorithm should the report use?
SHA-256 for anything that may be scrutinised. MD5 only if you are matching a legacy checksum, since it cannot prove a file was not deliberately altered.
Does generating a report upload anything?
No. The PDF is assembled in your browser and saved directly to your downloads. Nothing reaches a server at any point.