How to file integrity monitor — detect silent corruption in archived files
- Step 1Confirm a Pro plan or higher and check sizes — The File Integrity Monitor requires Pro or above. Pro allows files up to 100 MB each, Pro-media 500 MB, and Developer 2 GB. Archived media masters and disk images are often large, so a multi-hundred-megabyte file may need Pro-media or Developer. The Free tier does not include this tool.
- Step 2Retrieve a pristine reference copy — Because the tool compares two files, you need a copy you trust as good — a duplicate held on separate media, a copy from a different storage pool, or a freshly verified restore. If you only kept a recorded digest from when the file was new, see the cookbook: fingerprint the archived copy with multi-hash-fingerprinter and compare its SHA-256 to your stored value.
- Step 3Drop the pristine copy as A and the archived copy as B — Put the known-good copy in file A and the cold-storage copy in file B. The comparison is symmetric so order does not change the verdict, but pristine-as-A keeps the report readable. 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-by-byte scan from offset 0 to find the first divergence. - Step 5Read the verdict and locate the rot —
identical: truemeans the archive is intact — log it as verified for this cycle.identical: falsemeans corruption is present; readfirstDiffOffsetfor where, and the hex window for what changed. An offset equal to the archived file's size means the tail was lost; a mid-file offset at equal size means in-place bit-rot. - Step 6Download the report for your retention log — Export integrity-report.json and file it with the archive's records. It carries both names, sizes, full SHA-256 digests, the identical flag, the offset, and the hex windows — a dated record of the archive's condition you can revisit on the next verification cycle.
Corruption signatures and what they tell you
Reading integrity-report.json to characterize archive degradation. The pattern of the offset distinguishes rot from truncation.
| Result | Likely cause | Interpretation |
|---|---|---|
identical: true | None — archive intact | No degradation detected this cycle; safe to keep storing |
identical: false, mid-file offset, equal sizes | Bit-rot — cells/sectors flipped in place | Silent corruption; restore the affected file from another copy |
identical: false, offset == archived size | Lost tail — a bad sector dropped the file's end | Truncation in storage; the original is the source of truth |
identical: false, many scattered diffs (digest differs early) | Widespread media failure | The medium is failing; migrate everything off it now |
Plan limits for archive checks
Pro and above only. Limits are per file; you always compare exactly two, so per-file size is the binding constraint for large archives.
| Plan | Available? | Max size per file | Typical archive fit |
|---|---|---|---|
| Free | No | — | Not included; minimum is Pro |
| Pro | Yes | 100 MB | Documents, photos, smaller masters |
| Pro-media | Yes | 500 MB | Media masters, design archives |
| Developer | Yes | 2 GB | Disk images and large media |
What this tool covers for archives
The File Integrity Monitor compares two files now. For neighbouring archive tasks, the right sibling tool is listed.
| Need | This tool | Use instead |
|---|---|---|
| Is this archived copy still identical to the original? | Yes — SHA-256 of each, compared, plus first-diff offset | — |
| Record baseline digests to re-check archives later | Computes SHA-256 of each, but compares two files now | multi-hash-fingerprinter to store md5 / sha-1 / sha-256 / sha-512 baselines |
| Is the file's entropy abnormal (e.g. encrypted/packed)? | No | entropy-analyzer |
| Examine the file's header bytes broadly | Only the 16 bytes at the divergence point | hex-header-inspector |
Cookbook
Bit-rot and cold-storage 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 archived master is still intact
You hold a duplicate of a video master on separate media. A digest match on the yearly check proves the cold-storage copy has not degraded.
file A: master-edit.mov (pristine dup, 471,859,200 bytes)
file B: master-edit.mov (cold storage, 471,859,200 bytes)
integrity-report.json:
{
"fileA": { "name": "master-edit.mov", "size": 471859200, "sha256": "9f86d081...a08f" },
"fileB": { "name": "master-edit.mov", "size": 471859200, "sha256": "9f86d081...a08f" },
"identical": true,
"firstDiffOffset": -1,
"firstDiffHex": null
}
Verdict: match -> archive intact this cycle. (Needs Pro-media for 450 MB.)Catch a single-bit flip in a photo archive
A decade-old JPEG developed one flipped bit. Same size, same name, but the digests differ and the offset points to the exact corrupted byte.
file A: wedding-2016.jpg (pristine, 6,291,456 bytes)
file B: wedding-2016.jpg (archived, 6,291,456 bytes)
integrity-report.json:
{
"fileA": { "name": "wedding-2016.jpg", "size": 6291456, "sha256": "7d865e95...4e2a" },
"fileB": { "name": "wedding-2016.jpg", "size": 6291456, "sha256": "83214a9c...11df" },
"identical": false,
"firstDiffOffset": 1048572,
"firstDiffHex": {
"a": "ffd8ffe000104a464946000101006000600",
"b": "ffd8ffe000104a464946000101006000400"
}
}
Byte 1048572 differs by one bit -> bit-rot. Restore from the pristine copy.Detect a lost tail from a bad sector
A bad sector at the end of the archive dropped the file's tail. The archived copy is a clean prefix of the original — firstDiffOffset equals the archived size and B's hex window is empty.
file A: backup-2020.tar.gz (pristine, 104,857,600 bytes)
file B: backup-2020.tar.gz (archived, 98,566,144 bytes)
integrity-report.json:
{
"fileA": { "name": "backup-2020.tar.gz", "size": 104857600, "sha256": "a1b2c3d4...0011" },
"fileB": { "name": "backup-2020.tar.gz", "size": 98566144, "sha256": "44556677...8899" },
"identical": false,
"firstDiffOffset": 98566144,
"firstDiffHex": {
"a": "1f8b0800000000000003ecbd0b7c5455b9",
"b": ""
}
}
Offset == archived size -> tail lost to a bad sector. Original is authoritative.Diagnose a failing medium from an early divergence
The digests differ within the first few bytes — the header itself is corrupt, a sign the storage medium is failing rather than a single stray flip. Time to migrate everything off it.
file A: project.psd (pristine, 209,715,200 bytes)
file B: project.psd (archived, 209,715,200 bytes)
integrity-report.json:
{
"fileA": { "name": "project.psd", "size": 209715200, "sha256": "2c26b46b...9a3b" },
"fileB": { "name": "project.psd", "size": 209715200, "sha256": "d4735e3a...c2f1" },
"identical": false,
"firstDiffOffset": 2,
"firstDiffHex": {
"a": "38425053000100000000000000030000",
"b": "384200530001000000000000ff030000"
}
}
Header corrupt at byte 2 -> suspect failing media; migrate the whole volume.Verify an archive against a digest recorded at write time
You only saved the SHA-256 from when the file was new, not a full copy. Use the fingerprinter to compute the archived file's digest and compare it to your stored value.
Stored at write time (2018): document-archive.7z sha-256: 5f4dcc3b5aa765d61d8327deb882cf99... Now - run /security-tools/multi-hash-fingerprinter on the archived file: sha-256: 5f4dcc3b5aa765d61d8327deb882cf99... Compare: stored == current -> archive intact, no rot. (If you keep a full pristine copy instead of just a digest, drop both here to also get the exact corruption offset when they ever diverge.)
Edge cases and what actually happens
Archive matches the pristine copy
IdenticalThe SHA-256 digests are equal, so the report returns identical: true, firstDiffOffset: -1, and firstDiffHex: null. No byte scan runs — the match alone certifies the archived copy is intact this cycle. Record the report and re-check on your next verification interval.
A single bit flipped in place
DifferentClassic bit-rot: same size, same name, but one bit changed. The digests differ and firstDiffOffset points to the exact byte, with the hex window showing the original versus the corrupted value differing by a single bit. Restore the file from the pristine copy; the rot is real even though nothing else flagged it.
Archived copy lost its tail (a clean prefix)
By designIf the archived copy matches the original for its whole length and then ends, the scan runs out of bytes in the shorter file. firstDiffOffset is the archived file's byte length and its hex window is empty. This is a lost tail — a bad sector dropped the end. The pristine copy is the source of truth.
Same size but the bytes differ
DifferentEqual sizes never prove identical content — bit-rot flips bits without changing length. The tool compares digests, not sizes, so same-size degradation is caught and firstDiffOffset localizes it. This is precisely the corruption a size or timestamp check is blind to.
An archive exceeds your plan's per-file limit
RejectedEach file is checked against your plan's security size cap before hashing. A 1 GB media master on Pro (100 MB) or Pro-media (500 MB) fails with a message naming the file, its size, and the cap. Large archives need the Developer tier (2 GB); beyond that they cannot be compared here.
Difference falls within the last 16 bytes of the file
ExpectedThe hex window is up to 16 bytes starting at the divergence offset. If the rot lands near the end of the file, the window simply returns fewer than 16 bytes. The firstDiffOffset is still exact; only the preview length shrinks.
You only kept a digest, not a full pristine copy
Out of scopeThis tool compares two files; it cannot check a single archive against a stored hash string. Fingerprint the archived file with multi-hash-fingerprinter and compare its SHA-256 to the value you recorded at write time. Keeping a full pristine copy lets you also get the exact corruption offset here.
Both files are empty (0 bytes)
IdenticalTwo empty files share the SHA-256 of the empty input, so the report returns identical: true with offset -1. An empty archived copy compared against a non-empty original differs at offset 0 — the empty file is a zero-length prefix — which would itself signal a total loss of the archived data.
A large archive makes the tab slow
ExpectedBoth files are read fully into memory before hashing — there is no background streaming. Comparing two near-2 GB archives uses heavy memory and pauses noticeably while the buffers load and digests compute. Close other tabs and avoid concurrent in-tab tools for the largest checks.
Fewer than two files dropped
RejectedThe tool needs exactly two files. With fewer it stops at Drop two files to compare. and produces no report. To fingerprint a single archived file on its own, use multi-hash-fingerprinter.
Frequently asked questions
What is bit-rot and why won't my filesystem warn me about it?
Bit-rot is silent, gradual corruption of stored data — flipped bits from media aging, leaking SSD charge, or decaying discs. Most filesystems do not checksum file content, so a flipped bit changes neither the size nor the modified date and goes unnoticed. A byte-level SHA-256 comparison against a known-good copy is what surfaces it.
Does my archive get uploaded to check for corruption?
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 a server, so irreplaceable originals, legal archives, and personal media never travel over a network.
Which hash does it use to detect rot?
SHA-256. The pristine copy and the archived copy are each hashed with SHA-256 in parallel and the two 64-character hex digests are compared. Any single flipped bit changes the digest, so a match is strong evidence the archive is intact.
How do I tell a single-bit flip from a failing drive?
Look at the divergence. A single isolated mismatch mid-file (digests differ only because of one byte) suggests a stray flip you can recover by restoring that file. A divergence in the first few bytes, or a digest that differs because corruption starts early, points to broader media failure — migrate everything off that medium.
Can it check a single archive against a hash I saved years ago?
Not directly — it compares two files, not a file against a stored hash string. Fingerprint the archived file with multi-hash-fingerprinter and compare its SHA-256 to your recorded value. If you keep a full pristine copy instead, drop both here to also get the exact corruption offset.
Will it catch corruption anywhere in the file, or only near the start?
Anywhere. The first-difference scan walks both files from offset 0 with no cap and stops at the first mismatch, so it locates rot wherever it occurs. Only the hex preview is capped — to 16 bytes from each file at the break point.
Does a lost file tail look different from in-place rot?
Yes. If the archived copy is a clean prefix of the original and then ends, firstDiffOffset equals the archived file's size and its hex window is empty — that is a lost tail (a bad sector). In-place rot keeps the size the same and shows a mid-file offset with a non-empty hex window on both sides.
Can it tell whether a file was encrypted or just corrupted?
No — it only reports whether two files differ and where. To judge whether a file's byte distribution looks like encryption or packing, use entropy-analyzer. This tool answers integrity, not the nature of the content.
How big a file can I check for rot?
Up to your plan's per-file cap: Pro 100 MB, Pro-media 500 MB, Developer 2 GB each. Both files are loaded into memory in the tab, so very large archives use a lot of RAM and take a moment to hash.
Does the filename affect the rot check?
No. Only bytes are hashed; filenames are recorded in the report verbatim but never affect the verdict. A pristine copy and an archived copy with different names will still report identical: true if their bytes match.
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. Because you compare exactly two files, the per-file size cap is the binding limit for large archives.
What should I keep as a record that an archive was checked?
Download integrity-report.json and file it with the archive's retention records. It captures both filenames, sizes, full SHA-256 digests, the identical flag, the first-diff offset and hex windows — a dated, self-contained record of the archive's condition at that check. For long-term baselines, also record digests 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.