How to file integrity monitor — compare two files for tampering
- Step 1Confirm you are on a Pro plan or higher — The File Integrity Monitor requires a Pro plan (or higher). Pro allows files up to 100 MB each; Pro-media raises that to 500 MB; Developer to 2 GB. The Free tier does not include this tool. Because the comparison always uses exactly two files, the per-plan batch-file count is never the binding constraint here — the per-file size is.
- Step 2Drop file A and file B — The tool takes exactly two files — a 'file A' and a 'file B' upload. Order does not affect the result (the comparison is symmetric), but by convention put your known-good / reference copy as A and the suspect / candidate copy as B so the report reads naturally. If you supply fewer than two files the tool stops with
Drop two files to compare. - Step 3Run the comparison — On submit, both files are read fully into memory and hashed in parallel with SHA-256. If the two digests are equal the report sets
identical: trueandfirstDiffOffset: -1. If they differ, the tool then scans both byte arrays from offset 0 to find the first index where they disagree. - Step 4Read the identical / different verdict — The headline result is the boolean
identical.truemeans the SHA-256 digests matched — the files are byte-for-byte the same.falsemeans at least one byte differs, the files are NOT the same, and a divergence offset has been computed. - Step 5Inspect the first-difference offset and hex window — When
identicalis false,firstDiffOffsetgives the zero-based byte position of the first divergence, andfirstDiffHexgives a 16-byte hex slice from file A and from file B starting at that offset. Compare the two hex strings side by side to see exactly what changed at the break point. - Step 6Download the JSON integrity report — Export
integrity-report.jsonfor your records. It containsfileAandfileBobjects (each withname,size, andsha256), theidenticalflag,firstDiffOffset, andfirstDiffHex. Archive it alongside the files, or paste the SHA-256 values into a ticket, dispute record, or chain-of-custody form.
What the report contains
Every field in the integrity-report.json the tool produces, and what it means. There are no options to configure — the report shape is fixed.
| Field | Type | Meaning |
|---|---|---|
fileA.name / fileB.name | string | The original filename of each uploaded file, copied verbatim from the upload |
fileA.size / fileB.size | number | The byte size of each file. Equal sizes do NOT imply identical content — a flipped byte leaves size unchanged |
fileA.sha256 / fileB.sha256 | string | The full lowercase hex SHA-256 digest of each file, computed with the Web Crypto API |
identical | boolean | true when the two SHA-256 digests are equal (byte-identical files); false otherwise |
firstDiffOffset | number | -1 when identical. Otherwise the zero-based index of the first differing byte. If one file is an exact prefix of the other, this equals the length of the shorter file |
firstDiffHex | object or null | null when identical. Otherwise { a, b }, each a hex string of up to 16 bytes from that file starting at firstDiffOffset |
Plan limits for the File Integrity Monitor
The tool runs only on Pro and above. Limits are per file; the comparison always uses exactly two files, so the per-file size cap is the constraint that matters.
| Plan | Available? | Max size per file | Notes |
|---|---|---|---|
| Free | No | — | This tool is not included on the Free tier; the minimum is Pro |
| Pro | Yes | 100 MB | Each of the two files must be 100 MB or smaller |
| Pro-media | Yes | 500 MB | Suited to large disk images, VM snapshots, and media masters |
| Developer | Yes | 2 GB | Largest per-file cap; both files are still read into memory in the tab |
What this tool does and does not do
The File Integrity Monitor is a single deterministic byte-level comparison. For anything beyond that, the right sibling tool is listed.
| Question | This tool | Use instead |
|---|---|---|
| Are these two files byte-identical? | Yes — SHA-256 of each, compared | — |
| What is the SHA-256 of one file? | Computed, but you need two files to run it | multi-hash-fingerprinter for a single file's md5 / sha-1 / sha-256 / sha-512 |
| Where do the files first differ? | Yes — firstDiffOffset + 16-byte hex windows | — |
| Why are these files different (semantic diff)? | No — it is byte-level only | A format-aware diff tool (e.g. PDF diff in the PDF suite) |
| Is this file's type forged or its extension lying? | No | magic-byte-validator |
| What do the file's header bytes look like? | Only the 16 bytes at the divergence point | hex-header-inspector |
Cookbook
Real comparison scenarios for audit and forensic work, with the JSON report each one produces. Hashes are truncated for readability; the tool emits the full 64-hex-character SHA-256.
Verify a restored backup against the original
The most common case: you restored a file from backup and need to prove it matches the source byte for byte. Identical SHA-256 digests are conclusive — there is no need to read further into the report.
file A: invoice-archive.zip (reference, 48,201,344 bytes)
file B: invoice-archive.zip (restored, 48,201,344 bytes)
integrity-report.json:
{
"fileA": { "name": "invoice-archive.zip", "size": 48201344, "sha256": "9f86d081...a08f" },
"fileB": { "name": "invoice-archive.zip", "size": 48201344, "sha256": "9f86d081...a08f" },
"identical": true,
"firstDiffOffset": -1,
"firstDiffHex": null
}
Verdict: digests match -> the restore is byte-perfect.Detect a single-byte tamper
Same size, different content — exactly the case a size check would miss. The report flags the mismatch and pinpoints the flipped byte, with the hex window showing the before/after value.
file A: contract-final.pdf (reference, 102,400 bytes)
file B: contract-final.pdf (suspect, 102,400 bytes)
integrity-report.json:
{
"fileA": { "name": "contract-final.pdf", "size": 102400, "sha256": "2c26b46b...9a3b" },
"fileB": { "name": "contract-final.pdf", "size": 102400, "sha256": "d4735e3a...c2f1" },
"identical": false,
"firstDiffOffset": 51873,
"firstDiffHex": {
"a": "2435302e30302055534400000000000000",
"b": "2435352e30302055534400000000000000"
}
}
Byte 51873: A shows '$50.00 USD', B shows '$55.00 USD'. Tamper located.Catch a truncated download (one file is a prefix of the other)
An installer download was cut short. The first 4 MB are identical, then file B simply ends. Because the shorter file is an exact prefix of the longer, firstDiffOffset equals the length of the truncated file, and file B's hex window is empty.
file A: setup.exe (reference, 8,388,608 bytes)
file B: setup.exe (download, 4,194,304 bytes)
integrity-report.json:
{
"fileA": { "name": "setup.exe", "size": 8388608, "sha256": "a1b2c3d4...0011" },
"fileB": { "name": "setup.exe", "size": 4194304, "sha256": "ffeeddcc...9988" },
"identical": false,
"firstDiffOffset": 4194304,
"firstDiffHex": {
"a": "504b0304140000000800abcd1234567890",
"b": ""
}
}
Offset == size of B -> B is a clean prefix of A -> download truncated.Spot a re-saved file whose header changed
An image was opened and re-exported by an editor. The pixel data may be visually identical, but a metadata or header block at the very front differs — so the divergence offset is tiny and the verdict is decisive.
file A: evidence.png (original, 2,097,152 bytes)
file B: evidence.png (re-saved, 2,098,003 bytes)
integrity-report.json:
{
"fileA": { "name": "evidence.png", "size": 2097152, "sha256": "7d865e95...4e2a" },
"fileB": { "name": "evidence.png", "size": 2098003, "sha256": "83214a9c...11df" },
"identical": false,
"firstDiffOffset": 33,
"firstDiffHex": {
"a": "0000000d49484452000004000000030000",
"b": "0000002274455874536f667477617265ff"
}
}
Divergence at byte 33: B inserted a tEXt 'Software' chunk -> re-saved, not original.Build a chain-of-custody record
For evidentiary handling, the report itself is the artefact. You archive integrity-report.json alongside the two files so a later reviewer can confirm the seized copy matched the working copy at the time of comparison.
file A: drive-image-seized.dd (sealed, 524,288,000 bytes)
file B: drive-image-working.dd (analysis copy, 524,288,000 bytes)
integrity-report.json (archived with case ID CR-2026-0413):
{
"fileA": { "name": "drive-image-seized.dd", "size": 524288000, "sha256": "e3b0c442...b855" },
"fileB": { "name": "drive-image-working.dd", "size": 524288000, "sha256": "e3b0c442...b855" },
"identical": true,
"firstDiffOffset": -1,
"firstDiffHex": null
}
Matching SHA-256 -> the working copy is a faithful duplicate of the sealed image.
For a multi-algorithm record (md5 + sha-1 + sha-512 too) of each image, run
/security-tools/multi-hash-fingerprinter on them individually as well.Edge cases and what actually happens
Only one file supplied
RejectedThe tool requires exactly two files. If fewer than two are provided it stops with the error Drop two files to compare. and produces no report. To compute the hash of a single file on its own, use multi-hash-fingerprinter instead, which fingerprints one file.
A file exceeds your plan's per-file size limit
RejectedEach file is checked against your plan's security file-size cap before hashing. If either file is over the limit, the run fails with a message naming the file, its size, and the cap (for example, exceeding the 100 MB Pro limit). Upgrade to Pro-media (500 MB) or Developer (2 GB), or compare smaller files.
Files are byte-identical
IdenticalThe SHA-256 digests match, so the report sets identical: true, firstDiffOffset: -1, and firstDiffHex: null. No byte scan is performed — the cryptographic match alone is conclusive proof the two files are the same.
Same size but different content
By designEqual byte sizes never imply identical content — a single flipped byte leaves the size untouched. The tool compares SHA-256 digests, not sizes, so a same-size tamper is caught and firstDiffOffset points to the changed byte. This is precisely the case a length or quick-glance check would miss.
One file is an exact prefix of the other (truncation)
By designIf the shorter file matches the longer one for its entire length and then simply ends, the diff scan runs out of bytes in the shorter file. firstDiffOffset is reported as the length of the shorter file, and that file's hex window in firstDiffHex is empty because there are no bytes there to show. This is the signature of a truncated download or a cut-off copy.
Difference falls within the last 16 bytes of a file
ExpectedThe hex window is up to 16 bytes starting at the divergence offset. If the first difference is near the end of a file, the window simply returns fewer than 16 bytes (whatever remains). The firstDiffOffset is still exact; only the preview length shrinks.
Both files are empty (0 bytes)
IdenticalTwo empty files have the same SHA-256 (the digest of the empty input), so the report returns identical: true with offset -1. An empty file compared against a non-empty one differs at offset 0, since the empty file is a zero-length prefix of the other.
Files differ only in metadata, not visible content
DifferentByte-level comparison cannot tell a meaningful content change from a metadata-only one — any differing byte sets identical: false. A re-saved document that rewrote a timestamp or producer string will show as different even if it looks unchanged. To strip volatile metadata before comparing, use the relevant family scrubber; to understand a format-aware difference, use a semantic diff tool (e.g. PDF diff in the PDF suite).
You want to know why files differ, not just where
Out of scopeThis is a byte-level integrity check: it reports whether and where two files diverge, never the semantic reason. For a meaningful diff of PDF or document content, use a format-aware diff tool. To investigate file headers more broadly than the 16-byte window, use hex-header-inspector; to check whether an extension matches the real file type, use magic-byte-validator.
A very large file makes the browser tab slow
ExpectedBoth files are read fully into memory in the tab before hashing — there is no background streaming. With files near the 2 GB Developer cap, expect heavy memory use and a noticeable pause while the buffers load and the digests compute. Close other tabs and avoid running additional in-tab tools concurrently for the largest comparisons.
Frequently asked questions
Does this tool upload my files to a server?
No. The File Integrity Monitor runs entirely in your browser. Both files are read into memory via the File API and hashed locally with the Web Crypto API (crypto.subtle.digest). Nothing is sent anywhere, which is what makes it safe for sealed evidence, confidential contracts, and proprietary binaries.
Which hash algorithm does it use?
SHA-256. Each of the two files is hashed with SHA-256 in parallel, and the two 64-character hex digests are compared. SHA-256 is collision-resistant for practical integrity purposes — a match means the files are byte-identical. If you also need MD5, SHA-1, or SHA-512 of a file, run multi-hash-fingerprinter on it separately.
Is there a limit on how much of the file the difference check covers?
No. The first-difference scan walks both files byte by byte from offset 0 until it finds a mismatch, with no cap — it can locate a divergence anywhere in the file, not just near the start. (An earlier description mentioning a '100 KB' window was inaccurate; the scan covers the whole file.) What is capped is the hex preview at the break point, which is up to 16 bytes from each side.
How big is the hex preview window?
Up to 16 bytes from each file, starting at firstDiffOffset, rendered as a hex string in firstDiffHex.a and firstDiffHex.b. If the divergence is within the last few bytes of a file, that file's window simply contains fewer than 16 bytes.
What does firstDiffOffset mean exactly?
It is the zero-based byte index of the first position where the two files differ. When the files are identical it is -1. When one file is an exact prefix of the other (a truncation), it equals the byte length of the shorter file — the point at which the shorter file ran out of bytes.
Does it work on binary files, not just text?
Yes. The comparison is purely byte-level, so it treats every file type the same — executables, disk images, ZIPs, PDFs, images, video. There is no parsing or interpretation of content; it only looks at raw bytes.
Why does it say the files differ when they look the same to me?
Because the check is byte-level, not visual. A re-saved file can carry a rewritten metadata or header block that changes bytes without changing how it renders. Any single differing byte sets identical to false. The firstDiffOffset and hex window tell you where the change is, which often reveals a header or metadata edit rather than a content edit.
Can it tell me what semantically changed in a PDF or DOCX?
No — it reports whether and where the bytes differ, not the meaning of the change. For a content-aware comparison of PDFs use a semantic PDF diff tool in the PDF suite. This tool's job is the cryptographic integrity verdict and the exact divergence offset.
What if the two files have different sizes?
Different sizes guarantee the files differ, so identical is false. The diff scan compares bytes up to the length of the shorter file; if every one of those bytes matches, the shorter file is a prefix of the longer one and firstDiffOffset is set to the shorter file's length. Otherwise the offset is wherever the first mismatch occurs.
Do I need a paid plan to use it?
Yes. The File Integrity Monitor is a Pro-tier (and above) tool; it is not on the Free plan. Pro supports files up to 100 MB each, Pro-media up to 500 MB, and Developer up to 2 GB. Since you always compare exactly two files, the per-file size limit is the relevant one, not any batch count.
Can I compare more than two files at once?
No. The tool takes exactly two files — file A and file B. To check several files against one reference, run the comparison once per pair. For an independent fingerprint of each file (handy when verifying many files against published hashes), multi-hash-fingerprinter gives you per-file digests you can compare manually.
How should I use the report for an audit or dispute?
Download integrity-report.json and archive it with the two files. It records both file names, sizes, full SHA-256 digests, the identical flag, the divergence offset, and the hex windows — a self-contained record. For a stronger multi-algorithm trail, also fingerprint each file with multi-hash-fingerprinter, and if you need to encrypt the evidence bundle afterward, use aes-256-encryptor.
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.