How to file integrity monitor — verify a download against a known-good copy
- Step 1Confirm you are on a Pro plan or higher and check the size — The File Integrity Monitor needs a Pro plan or above. Pro allows files up to 100 MB each, Pro-media up to 500 MB, and Developer up to 2 GB. ISOs and large installers can easily exceed 100 MB, so a multi-gigabyte disc image needs the Developer tier. The Free tier does not include this tool.
- Step 2Get a trusted reference copy — Because the tool compares two files, you need a copy you already trust as file A — for example one pulled from the publisher's primary HTTPS host, copied from sealed install media, or a build you verified earlier. If all you have is a published hash string and a single download, see the cookbook: compute the download's digest with multi-hash-fingerprinter and compare it to the published value by eye.
- Step 3Drop the reference as A and your download as B — Put the trusted copy in the file A slot and the freshly downloaded file in file B. Order does not change the math (the comparison is symmetric), but A-as-reference keeps the report readable. Supplying fewer than two files stops the run with
Drop two files to compare. - Step 4Run the comparison — On submit, both files are read fully into memory and hashed with SHA-256 in parallel. Equal digests set
identical: trueandfirstDiffOffset: -1. Different digests trigger a byte scan from offset 0 to locate the first divergence. - Step 5Read the verdict and locate any divergence —
identical: truemeans your download matches the trusted copy byte for byte — safe to install.identical: falsemeans it differs; checkfirstDiffOffset. If it equals file B's size, the download is a clean prefix of the reference (truncated). If it is small or mid-file, the bytes were altered, not merely cut short. - Step 6Download and keep the JSON report — Export integrity-report.json and store it with the installer or attach it to your deployment record. It carries both names, sizes, full SHA-256 digests, the identical flag, the offset, and the hex windows — enough for a reviewer to confirm what was verified and when.
How to read the verdict for a download
Interpreting integrity-report.json fields specifically for download verification. firstDiffOffset is the most diagnostic field after the identical flag.
| Report state | What it means for your download | Action |
|---|---|---|
identical: true | Download is byte-for-byte the same as the trusted copy | Safe to install or deploy |
identical: false, firstDiffOffset == size of B | B is an exact prefix of A — the download was truncated (dropped connection / cut-off transfer) | Re-download in full; do not run a partial installer |
identical: false, small or mid-file offset | Bytes were altered or it is a different build — possible stale mirror, proxy rewrite, or tamper | Re-fetch from the primary host; inspect the hex window before trusting it |
identical: false, sizes differ but not a prefix | Different content and length — almost certainly a different file/version, not your reference | Confirm you compared the right two files and versions |
Plan limits for verifying downloads
The tool runs on Pro and above. Limits are per file. ISOs and large installers often need the higher tiers.
| Plan | Available? | Max size per file | Typical fit |
|---|---|---|---|
| Free | No | — | Not included; minimum is Pro |
| Pro | Yes | 100 MB | App installers, drivers, smaller archives |
| Pro-media | Yes | 500 MB | Large installers, mid-size disk images |
| Developer | Yes | 2 GB | OS ISOs and full disc images |
What this tool does vs. what you might expect
Common download-verification expectations and whether this tool covers them.
| Want to... | This tool | Use instead |
|---|---|---|
| Compare my download to a trusted copy | Yes — SHA-256 of each, compared, with first-diff offset | — |
| Check a single download against a published hash string | No — it needs two files, not a hash string | multi-hash-fingerprinter to get the digest, then compare by eye |
| Verify a PGP/GPG signature on a release | No — it is hash comparison, not signature verification | pgp-message-signer |
| Confirm an installer is the type it claims (.exe not .zip) | No | magic-byte-validator |
Cookbook
Download-verification scenarios with the JSON report each produces. SHA-256 digests are truncated for readability; the tool emits the full 64-hex-character value.
Confirm an ISO downloaded intact
You fetched a Linux ISO from a mirror and have a copy from the project's primary host. Matching SHA-256 digests prove the mirror served the genuine file.
file A: distro-25.04.iso (primary host, 3,221,225,472 bytes)
file B: distro-25.04.iso (mirror, 3,221,225,472 bytes)
integrity-report.json:
{
"fileA": { "name": "distro-25.04.iso", "size": 3221225472, "sha256": "e3b0c442...b855" },
"fileB": { "name": "distro-25.04.iso", "size": 3221225472, "sha256": "e3b0c442...b855" },
"identical": true,
"firstDiffOffset": -1,
"firstDiffHex": null
}
Verdict: digests match -> the mirror's ISO is genuine. (Needs Developer tier for 3 GB.)Catch a truncated installer from a dropped connection
The download bar reached 100% but the connection blipped near the end. The first bytes match the reference, then file B simply stops — firstDiffOffset equals B's size and B's hex window is empty.
file A: app-setup.exe (reference, 96,468,992 bytes)
file B: app-setup.exe (download, 62,914,560 bytes)
integrity-report.json:
{
"fileA": { "name": "app-setup.exe", "size": 96468992, "sha256": "a1b2c3d4...0011" },
"fileB": { "name": "app-setup.exe", "size": 62914560, "sha256": "77665544...3322" },
"identical": false,
"firstDiffOffset": 62914560,
"firstDiffHex": {
"a": "4d5a90000300000004000000ffff0000b8",
"b": ""
}
}
Offset == size of B -> clean prefix -> truncated. Re-download in full.Spot a stale build served by an out-of-sync mirror
The mirror handed you last week's build. Same filename, similar size, but the bytes diverge early — this is a different version, not a corrupted copy of yours.
file A: firmware-2.4.1.bin (current, 8,388,608 bytes)
file B: firmware-2.4.1.bin (mirror, 8,388,608 bytes)
integrity-report.json:
{
"fileA": { "name": "firmware-2.4.1.bin", "size": 8388608, "sha256": "5f4dcc3b...d8f2" },
"fileB": { "name": "firmware-2.4.1.bin", "size": 8388608, "sha256": "098f6bcd...a7c9" },
"identical": false,
"firstDiffOffset": 28,
"firstDiffHex": {
"a": "7665723a322e342e312d6275696c64313432",
"b": "7665723a322e342e312d6275696c64313337"
}
}
Byte 28: A is 'build142', B is 'build137' -> mirror is serving an old build.Verify a single download against a published hash (no reference file)
You only have one download and the publisher's posted SHA-256 string. This tool needs two files, so use the sibling fingerprinter to compute the digest, then compare it to the published value yourself.
Step 1 - run /security-tools/multi-hash-fingerprinter on app-setup.exe: sha-256: 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08 Step 2 - compare to the publisher's posted value, character by character: published: 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08 match -> the download is authentic. (Once you have a verified copy, keep it as your 'file A' reference so future downloads can be checked here directly.)
Approve a deployment with an attached integrity record
Before pushing an installer to a fleet, you compare the staged copy against the build-server original and archive the report with the change ticket.
file A: agent-installer.msi (build server, 41,943,040 bytes)
file B: agent-installer.msi (staging, 41,943,040 bytes)
integrity-report.json (attached to CHG-2026-1188):
{
"fileA": { "name": "agent-installer.msi", "size": 41943040, "sha256": "2c26b46b...9a3b" },
"fileB": { "name": "agent-installer.msi", "size": 41943040, "sha256": "2c26b46b...9a3b" },
"identical": true,
"firstDiffOffset": -1,
"firstDiffHex": null
}
Match -> the staged installer is the approved build. Ship it.Edge cases and what actually happens
You only have one file and a published hash string
Out of scopeThis tool compares two files; it does not accept a pasted hash string to check a single download against. Compute the download's SHA-256 with multi-hash-fingerprinter and compare it to the publisher's posted value yourself. Once you have one verified copy, keep it as the reference (file A) for future downloads.
Download is truncated (a clean prefix of the reference)
By designIf your download matches the reference for its whole length and then ends, the diff scan runs out of bytes in the shorter file. firstDiffOffset is reported as the download's byte length and its hex window is empty. This is the unmistakable signature of a dropped connection or cut-off transfer — re-download in full.
An ISO exceeds your plan's per-file limit
RejectedEach file is checked against your plan's security size cap before hashing. A 3 GB ISO on Pro (100 MB) or Pro-media (500 MB) fails with a message naming the file, its size, and the cap. Multi-gigabyte images need the Developer tier (2 GB); larger still cannot be compared here.
Download matches the reference exactly
IdenticalThe SHA-256 digests are equal, so the report returns identical: true, firstDiffOffset: -1, and firstDiffHex: null. No byte scan runs — the cryptographic match alone proves the download is the genuine, complete file.
Same size but the bytes differ (possible tamper or stale build)
DifferentEqual byte sizes never prove identical content. The tool compares digests, not sizes, so a same-size swap or a same-size stale build is caught and firstDiffOffset points to the first changed byte. Inspect the hex window: an early divergence in a header or version string usually means a different build rather than corruption.
You want to verify a release signature, not just a hash
Out of scopeThis tool checks byte-level integrity by hash; it does not verify a detached PGP/GPG signature that proves who built the file. For signature work use pgp-message-signer. A hash match confirms the file equals a copy you already trust; a signature confirms the publisher's identity — they answer different questions.
The installer's extension might be lying
Out of scopeByte comparison cannot tell you whether a .exe is secretly a ZIP or a script — it only compares two files to each other. To check that a download's real content type matches its extension, run magic-byte-validator before installing.
A multi-gigabyte image makes the tab sluggish
ExpectedBoth files are read fully into memory in the tab before hashing — there is no background streaming. Comparing two files near the 2 GB Developer cap uses heavy memory and pauses noticeably while the buffers load and the digests compute. Close other tabs and avoid running additional in-tab tools during the comparison.
Filenames differ but you expect the same content
ExpectedFilenames are recorded verbatim in the report but play no part in the comparison — only bytes are hashed. A reference named distro.iso and a download named distro-mirror.iso will still report identical: true if their bytes match. The names are there for your audit trail, not the verdict.
Fewer than two files dropped
RejectedThe tool requires exactly two files. With fewer it stops at Drop two files to compare. and produces no report. To fingerprint a single download on its own, use multi-hash-fingerprinter.
Frequently asked questions
Can I just paste the publisher's SHA-256 and check my one download against it?
Not in this tool — it compares two files, not a file against a hash string. Run multi-hash-fingerprinter on your download to get its SHA-256, then compare that digest to the publisher's posted value character by character. Once you trust one copy, keep it as the file A reference so future downloads can be compared here directly.
Does my download get uploaded anywhere to be checked?
No. Both files are read into the browser tab via the File API and hashed locally with the Web Crypto API (crypto.subtle.digest). Nothing is sent to the mirror, the publisher, or any server, so a confidential enterprise gold image is never transmitted.
Which hash does it use to verify the download?
SHA-256. Each file is hashed with SHA-256 in parallel and the two 64-character hex digests are compared. A match means the two files are byte-identical; SHA-256 is collision-resistant for practical integrity verification.
How do I tell a truncated download from a tampered one?
Look at firstDiffOffset. If it equals your download's byte size, the download is an exact prefix of the reference and then ends — that is a truncation, so re-download. If it is small or mid-file, bytes were altered: it could be a stale build or a tamper. The 16-byte hex window helps you see which.
Can it verify an ISO that is several gigabytes?
Yes, if you are on the Developer tier, which allows files up to 2 GB each. Pro caps each file at 100 MB and Pro-media at 500 MB. Both files are loaded into memory in the tab, so very large images use a lot of RAM and take a noticeable moment to hash.
Does verifying the hash also prove the publisher made it?
No. A hash match proves your download equals a copy you already trust; it says nothing about who built it. To verify the publisher's identity you need a digital signature — use pgp-message-signer for PGP signature work. Hash and signature answer different questions.
Why does it report a difference when the file installed fine?
Because the check is byte-level. A stale or slightly different build, or a proxy that rewrote a byte, can still install successfully while differing from your reference. Any single differing byte sets identical to false. The offset and hex window show you where it differs.
Does it matter which file I put in slot A versus slot B?
Not for the result — the comparison is symmetric, so the identical flag and offset are the same either way. By convention put the trusted reference as A and your download as B so the report reads naturally and your audit trail is unambiguous.
What if the two files have different sizes?
Different sizes guarantee they differ, so identical is false. The scan compares bytes up to the shorter file's length; if all of those match, the shorter file is a prefix of the longer one and firstDiffOffset is set to the shorter length (a truncation). Otherwise the offset is the first real mismatch.
Can it check that my .exe is really an executable and not a disguised script?
No — that is content-type detection, not file comparison. Use magic-byte-validator to confirm a download's real type matches its extension. This tool only tells you whether two files are byte-identical.
Do I need a paid plan?
Yes. The File Integrity Monitor is a Pro-tier (and above) tool and is not on the Free plan. Pro allows 100 MB per file, Pro-media 500 MB, and Developer 2 GB. Since you always compare exactly two files, the per-file size cap is what matters for large installers and ISOs.
What should I keep as proof that I verified a download?
Download integrity-report.json and archive it with the installer or attach it to your change ticket. It records both filenames, sizes, full SHA-256 digests, the identical flag, the first-diff offset and hex windows — a self-contained record a reviewer can trust. For a multi-algorithm record, also fingerprint each file with multi-hash-fingerprinter.
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.