How to multi-algorithm file hash fingerprinter
- Step 1Drop the file you want to verify — Drag the downloaded archive, installer, ISO, or evidence file onto the dropzone above. Any file type works — the tool hashes raw bytes, not parsed content. The dropzone accepts multiple files, but each run fingerprints the first file only (see the edge cases).
- Step 2Run the fingerprinter — The file's bytes are read into memory and digested with MD5, SHA-1, SHA-256, and SHA-512. SHA-1/256/512 run via
crypto.subtle.digest; MD5 runs in a small JS routine. There is nothing to configure — no algorithm picker, no options. - Step 3Read the four hashes — The result is a JSON object:
{ "sha1": "…", "sha256": "…", "sha512": "…", "md5": "…" }, all lowercase hex. Find the algorithm the publisher used and locate that line. - Step 4Compare against the published checksum — Match the relevant digest character-for-character against the vendor's published value. Hex is case-insensitive as a number, so uppercase a published
AB12…equals the tool's lowercaseab12…— compare case-insensitively, or lowercase the published value first. - Step 5Copy or download the report for your records — Copy the JSON to clipboard (the copy button copies the whole report, not a single line), or download it as
<filename>.hashes.jsonto attach to a build manifest, evidence log, or migration ticket. - Step 6Re-run on the destination copy to prove a transfer — After moving a file across a network, USB, or cloud sync, fingerprint the destination copy and confirm the SHA-256 still matches the source. Identical SHA-256 means the bytes survived the trip intact.
Algorithms computed (every run, all four)
There is no algorithm selector — every run returns all four digests. SHA-1/256/512 come from the browser's Web Crypto API; MD5 from a small embedded routine. Digest lengths and CLI equivalents below.
| Algorithm | Output (hex chars / bits) | Engine | Matches CLI | Use it for |
|---|---|---|---|---|
| MD5 | 32 hex chars / 128-bit | Embedded JS (RFC 1321) | md5sum, md5, certutil -hashfile … MD5 | Legacy mirrors and old vendor pages only — collision-broken, not safe for security |
| SHA-1 | 40 hex chars / 160-bit | Web Crypto (SHA-1) | sha1sum, shasum -a 1, git object IDs | Git blob/commit IDs, legacy signatures — collision-broken (SHAttered), avoid for new trust decisions |
| SHA-256 | 64 hex chars / 256-bit | Web Crypto (SHA-256) | sha256sum, shasum -a 256, certutil -hashfile … SHA256 | The default for download verification, SHA256SUMS files, and supply-chain checks |
| SHA-512 | 128 hex chars / 512-bit | Web Crypto (SHA-512) | sha512sum, shasum -a 512 | High-assurance archives and anything published as SHA-512 |
Where it runs, limits, and output
The fingerprinter is browser-first with a server-safe path for the runner/API. The whole file is read into memory before hashing — there is no streaming or chunking, so the practical ceiling is browser memory and your tier's file-size limit.
| Property | Value | Notes |
|---|---|---|
| Minimum plan | Free | Available on every tier; no upgrade needed to fingerprint a file |
| File-size limit (Free / Pro / Pro-media / Developer) | 10 MB / 100 MB / 500 MB / 2 GB | Security-family limits; a file over your tier's cap is rejected before hashing with a "exceeds the … limit" error |
| Files per run | 1 (the first dropped file) | The dropzone is multi-select, but each run hashes files[0] only — drop and run per file |
| Input format | Any file (raw bytes) | The tool digests bytes, not parsed content — text, binary, ISO, key, image all work |
| Output (browser) | JSON report { sha1, sha256, sha512, md5 }, all lowercase hex | Copy to clipboard or download as <filename>.hashes.json |
| Output (server-safe path) | JSON { md5, sha1, sha256, sha512, sizeBytes } | Same four digests plus the byte count; computed with Node's crypto on a paired runner |
| Options / presets | None | No algorithm toggles, no case option, no salt — the file is the only input |
Where each published format shows up — and which line to match
Vendors and mirrors publish checksums in different shapes. Whichever they used, the matching algorithm is already in the report.
| You see… | It's this algorithm | Match against the report's… |
|---|---|---|
SHA256SUMS file, or …sha256 next to a download | SHA-256 | sha256 (64 hex chars) |
A 32-char hex on an old mirror or MD5SUMS | MD5 | md5 (32 hex chars) |
| A 40-char hex, or a Git commit/blob ID | SHA-1 | sha1 (40 hex chars) |
…sha512 or a 128-char hex block | SHA-512 | sha512 (128 hex chars) |
A .asc / .sig signature file | Not a hash — it's a PGP signature | Verify with pgp-message-signer, not a checksum |
Cookbook
Real verification recipes. The tool's output is four hex strings; the work is matching the right one against what the publisher gave you. CLI equivalents are shown so you can cross-check from a terminal.
Verify a downloaded Linux ISO against SHA256SUMS
Distro mirrors publish a SHA256SUMS file listing the SHA-256 of each image. Drop the ISO, read the sha256 field, and confirm it matches the line for your file. A match means the download is bit-identical to what the project released.
Fingerprinter report (sha256 field): e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 Published SHA256SUMS line: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 ubuntu-24.04.iso Match -> download is intact. Terminal cross-check (same value): sha256sum ubuntu-24.04.iso
Match a legacy mirror that only publishes MD5
An old vendor page or FTP mirror may only list an MD5. MD5 is collision-broken for security, but for detecting accidental corruption on a trusted-source download it still tells you the bytes are intact. The matching md5 line is already in the report.
Fingerprinter report (md5 field): 9e107d9d372bb6826bd81d3542a419d6 Vendor page lists: MD5: 9E107D9D372BB6826BD81D3542A419D6 Match (hex is case-insensitive: lowercase 9e... == uppercase 9E...). Terminal cross-check: md5sum installer.bin # Linux certutil -hashfile installer.bin MD5 # Windows
Prove a file survived a transfer or USB copy intact
Before and after moving a large file across a flaky network or onto removable media, fingerprint both copies. Identical SHA-256 proves not a single byte changed. This is the integrity check that catches silent corruption a file size comparison misses.
Source copy -> sha256: 2c26b46b68ffc68ff99b453c1d304134... Dest copy -> sha256: 2c26b46b68ffc68ff99b453c1d304134... Identical -> transfer is verified. Differ -> the copy is corrupt; re-transfer the file. (A matching file size with a different hash = corruption you would not have caught any other way.)
Hash evidence and record it in an audit log
For chain-of-custody, fingerprint a sealed evidence file the moment you receive it and store the JSON report alongside it. Because hashing runs in your browser, the file never leaves your machine — important for confidential material. Re-hashing later and getting the same SHA-512 proves it was untouched.
Download the report -> evidence-001.pcap.hashes.json
{
"sha1": "da39a3ee5e6b4b0d3255bfef95601890afd80709",
"sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
"sha512": "cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e",
"md5": "d41d8cd98f00b204e9800998ecf8427e"
}
Archive the JSON with the file; re-hash later to prove no edits.Build a baseline, then watch for change over time
Fingerprinting tells you what a file is now; it cannot tell you whether it changed since last week. To monitor a file for tampering between two points in time, capture the SHA-256 as a baseline, then compare the two files directly later with the file-integrity tool.
Day 1: fingerprint config.bin -> sha256: 9b74c9897b... Day 30: fingerprint config.bin -> sha256: 5f4dcc3b5a... Digests differ -> the file was modified between the two dates. For a guided before/after diff of two files, use [file-integrity-monitor](/security-tools/file-integrity-monitor) which compares both copies and reports exactly what changed.
Edge cases and what actually happens
No file dropped before running
Error: no fileThe tool needs a file to hash — there is no text-paste mode. Running with an empty dropzone throws "No file provided." Drop a file first, then run. (For scoring a typed password instead of a file, use password-entropy-auditor.)
File is larger than your tier's limit
Rejected: too largeThe whole file is read into memory before hashing, so the size cap is enforced up front: Free 10 MB, Pro 100 MB, Pro-media 500 MB, Developer 2 GB. A file over your cap is rejected with an "exceeds the … limit for your plan" error before any digest is computed. There is no streaming path that would let a huge file through in chunks.
Multiple files dropped at once
First file onlyThe dropzone is multi-select (Pro allows up to 5 batch slots, Pro-media 50, Developer unlimited), but each run fingerprints files[0] only and returns one report. Drop and run per file, or script the server-safe runner path for true batch fingerprinting.
Published checksum is uppercase, the report is lowercase
ExpectedThe report always emits lowercase hex (the shasum/sha256sum convention). Many vendors and certutil print uppercase. Hex is case-insensitive as a value, so lowercase ab12… equals uppercase AB12… — compare case-insensitively or lowercase the published value first. This is not a mismatch.
MD5 or SHA-1 matches but you needed real security
Insecure algorithmMD5 and SHA-1 are collision-broken: an attacker can craft two different files with the same MD5 or SHA-1. A match proves the file equals a *trusted* reference, but it does not prove an untrusted file is safe. For any trust decision against an adversary, use the SHA-256 or SHA-512 line, not MD5/SHA-1.
Two visibly identical files produce different hashes
By designThe tool hashes raw bytes, so any byte-level difference flips the digest completely — a trailing newline, a different line-ending (CRLF vs LF), a re-encode, a BOM, or metadata embedded by a save dialog. "Looks the same" is not "is the same." If a text file's hash won't match, suspect line endings or encoding before suspecting corruption.
You have a `.asc` / `.sig` file, not a checksum
Wrong toolA .asc/.sig is a PGP/GPG signature, not a hash, and cannot be matched against the report. Signatures prove *who* released the file using a public key; checksums only prove the bytes match a published value. Verify signatures with pgp-message-signer.
You want to confirm a file's true type, not just its hash
Different toolA hash fingerprints exact bytes but says nothing about whether a .jpg is really a JPEG. To confirm a file's real type from its leading bytes, use magic-byte-validator; to inspect the raw header, use hex-header-inspector.
You want to know if a file is encrypted or packed
Different toolHashing won't tell you whether a blob is random/encrypted. For that, measure its byte distribution with entropy-analyzer — high entropy suggests encryption or compression; low entropy suggests plain text or structured data.
Server-safe path returns an extra field
ExpectedRun via the browser and the report is { sha1, sha256, sha512, md5 }. Run through a paired runner / the API server-safe path and you also get sizeBytes — the same four digests plus the input byte count. The digest values are identical between the two paths.
Frequently asked questions
Which hash should I use to verify a download?
SHA-256 unless the publisher specifies otherwise — it's the modern default for SHA256SUMS files and supply-chain verification. Use SHA-512 if the project publishes that. Only fall back to MD5 or SHA-1 if that's the only checksum the source provides, and treat a match from those as accidental-corruption detection (not adversary-proof security), because MD5 and SHA-1 are collision-broken. All four are in the report, so just pick the line that matches the published format.
Does the output match `shasum` / `sha256sum` / `certutil`?
Yes — byte-for-byte. SHA-1/256/512 are computed with the browser's Web Crypto API, the same standard primitive those CLIs use, and MD5 with a standard RFC-1321 routine. The report prints lowercase hex like sha256sum and shasum. certutil -hashfile on Windows prints uppercase, but that's the same value in a different case — compare case-insensitively.
Is my file uploaded anywhere?
No. The file is read into memory in your browser and hashed locally with the Web Crypto API — it never leaves your machine. That's why you can safely fingerprint a private key, a sealed evidence file, or a confidential internal build. The only thing recorded server-side for signed-in users is a single usage counter (no file content).
Can I pick which algorithms to compute?
No — there are no options. Every run computes all four (MD5, SHA-1, SHA-256, SHA-512) and returns them together. This is deliberate: you rarely know in advance which algorithm a mirror published, so having all four on screen means the matching one is always there. Just read the line you need and ignore the rest.
Why include MD5 if it's broken?
Because plenty of legacy mirrors, old vendor pages, and internal checksum lists still only publish MD5, and you need to be able to match them. MD5 is fine for detecting accidental corruption of a download from a trusted source. It is not safe against a deliberate attacker, who can craft two different files with the same MD5. For any security decision, use SHA-256 or SHA-512.
Can I hash multiple files at once?
Not in a single run. The dropzone accepts multiple files, but each run fingerprints the first file only and returns one report. Drop and run per file, or use the server-safe runner path to script batch fingerprinting. To compare two specific files for tampering, file-integrity-monitor takes both at once.
How big a file can I hash?
Up to your tier's security file-size limit: Free 10 MB, Pro 100 MB, Pro-media 500 MB, Developer 2 GB. The whole file is read into memory before hashing — there is no streaming — so very large files are bounded by both the tier cap and your browser's available memory. A file over the cap is rejected before any digest runs.
My text file's hash doesn't match — why?
Almost always line endings or encoding, not corruption. The tool hashes raw bytes, so a file saved with Windows CRLF line endings produces a different hash than the same text with Unix LF endings, and a UTF-8 BOM at the start changes every byte position. A trailing newline added by an editor also flips the digest. Normalize line endings/encoding so both files are byte-identical, then re-hash.
What format is the output?
A JSON object of lowercase hex strings: { "sha1": "…", "sha256": "…", "sha512": "…", "md5": "…" }. The copy button copies the whole object; the download saves it as <filename>.hashes.json. Via the server-safe path you also get a sizeBytes field with the input length. There is no CSV/per-line export from the browser tool — it's a single JSON report.
Can a hash tell me if a file changed since last week?
Only if you saved the earlier hash. A single fingerprint describes the file as it is now; it can't see the past. Capture the SHA-256 as a baseline and re-fingerprint later — different digest means the bytes changed. For a guided before/after comparison of two copies of a file, use file-integrity-monitor, which diffs both and reports the change.
How is this different from a PGP signature?
A checksum proves the file matches a *published value*; a PGP signature proves *who released it* using their public key. A hash alone doesn't authenticate the publisher — if an attacker controls the mirror, they can replace both the file and its checksum. The strongest verification is to check a PGP signature (pgp-message-signer) over a published SHA256SUMS, then match the file's SHA-256 against that signed list.
Can I run this as an automated pipeline?
Yes — the fingerprinter is server-safe, so it works through a paired @jadapps/runner without files leaving your machine. GET /api/v1/tools/multi-hash-fingerprinter returns the tool schema, then POST your payload to the local runner at http://127.0.0.1:9789/v1/tools/multi-hash-fingerprinter/run. The hosted /api/v1/tools/.../run endpoint is intentionally upload-free and returns pairing instructions; install the runner from /docs/runner. The server-safe response includes the four digests plus sizeBytes.
Privacy first
Every JAD Security operation runs entirely in your browser. Files, passwords, and PGP private keys never leave your device — verified by zero outbound network requests during processing.