How to file integrity monitor — confirm a transfer arrived intact
- 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. Bulk transfers 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 2Keep both ends of the transfer — You need the source file (the copy on the system you transferred from) and the received file (the copy that landed on the destination). Bring both to the same machine — for example, the original on disk and the just-downloaded copy — so you can drop them together.
- Step 3Drop the source as A and the received copy as B — Put the source in file A and the received copy in file B. The comparison is symmetric so order does not change the result, but source-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 diagnose any fault —
identical: truemeans the transfer is clean.identical: falsemeans the copy differs; readfirstDiffOffsetand the hex window. Line-ending bytes (0d 0a vs 0a) diverging point to an ASCII-mode FTP rewrite; an offset equal to the received file's size means truncation; scattered mid-file diffs suggest a dropped-byte or bad-block fault. - Step 6Download the report for your transfer log — Export integrity-report.json and attach it to your transfer or handover record. It carries both names, sizes, full SHA-256 digests, the identical flag, the offset, and the hex windows — proof the moved file matched the source at the time of the check.
Transfer fault signatures
Diagnosing a failed transfer from integrity-report.json. The hex window at the offset often identifies the cause.
| Result / hex pattern | Likely transfer fault | Fix |
|---|---|---|
identical: true | None — clean transfer | Sign off; the copy matches the source |
A shows 0d0a, B shows 0a at the offset | FTP client in ASCII/text mode rewrote line endings | Re-transfer in binary mode |
firstDiffOffset == received file's size | Transfer cut off — connection dropped or quota hit | Re-transfer; confirm the full file completed |
| Scattered mid-file diffs, same size | Dropped bytes on the link or a USB bad-block write | Re-copy; consider a more reliable medium or protocol |
Plan limits for transfer verification
Pro and above only. Limits are per file; you always compare exactly two, so per-file size is the binding constraint for large transfers.
| Plan | Available? | Max size per file | Typical transfer fit |
|---|---|---|---|
| Free | No | — | Not included; minimum is Pro |
| Pro | Yes | 100 MB | Documents, datasets, small media |
| Pro-media | Yes | 500 MB | Large datasets and media files |
| Developer | Yes | 2 GB | Disk images and bulk archives |
What this tool covers for transfers
The File Integrity Monitor compares two files. For neighbouring transfer tasks, the right sibling tool is listed.
| Need | This tool | Use instead |
|---|---|---|
| Did the file arrive byte-for-byte identical? | Yes — SHA-256 of each, compared, plus first-diff offset | — |
| A standalone digest of one end to send with the file | Computes SHA-256, but needs two files to run | multi-hash-fingerprinter for a single file's md5 / sha-1 / sha-256 / sha-512 |
| Encrypt a file before transferring it | No | aes-256-encryptor |
| Confirm the received file's type matches its extension | No | magic-byte-validator |
Cookbook
File-transfer scenarios with the JSON report each produces. SHA-256 digests are truncated for readability; the tool emits the full 64-hex-character value.
Confirm a clean SFTP transfer
You pulled a dataset over SFTP in binary mode and kept the source. Matching SHA-256 digests prove the file landed exactly as it left.
file A: dataset.parquet (source, 88,080,384 bytes)
file B: dataset.parquet (received, 88,080,384 bytes)
integrity-report.json:
{
"fileA": { "name": "dataset.parquet", "size": 88080384, "sha256": "9f86d081...a08f" },
"fileB": { "name": "dataset.parquet", "size": 88080384, "sha256": "9f86d081...a08f" },
"identical": true,
"firstDiffOffset": -1,
"firstDiffHex": null
}
Verdict: match -> clean transfer. Sign off the handover.Catch an FTP ASCII-mode line-ending rewrite
An FTP client in text mode stripped carriage returns from a script. The files diverge at the first line break, and the hex window shows 0d0a on the source versus 0a on the copy.
file A: deploy.sh (source, 4,096 bytes)
file B: deploy.sh (received, 3,981 bytes)
integrity-report.json:
{
"fileA": { "name": "deploy.sh", "size": 4096, "sha256": "2c26b46b...9a3b" },
"fileB": { "name": "deploy.sh", "size": 3981, "sha256": "d4735e3a...c2f1" },
"identical": false,
"firstDiffOffset": 23,
"firstDiffHex": {
"a": "23212f62696e2f62617368 0d0a 23206465",
"b": "23212f62696e2f62617368 0a23 20646570"
}
}
Byte 23: A has 0d0a, B has 0a -> ASCII-mode rewrite. Re-transfer in binary.Detect a cut-off transfer over a flaky link
The connection dropped mid-copy. The received file matches the source up to a point and then ends — firstDiffOffset equals the received size and B's hex window is empty.
file A: export.csv (source, 52,428,800 bytes)
file B: export.csv (received, 39,845,888 bytes)
integrity-report.json:
{
"fileA": { "name": "export.csv", "size": 52428800, "sha256": "a1b2c3d4...0011" },
"fileB": { "name": "export.csv", "size": 39845888, "sha256": "66778899...aabb" },
"identical": false,
"firstDiffOffset": 39845888,
"firstDiffHex": {
"a": "2c323032362d30362d31332c75736572",
"b": ""
}
}
Offset == received size -> transfer cut off. Re-transfer the full file.Diagnose a USB bad-block write
A file copied to a USB drive came back with a corrupted block. Same size, but the digests differ and the divergence sits deep in the file — a write fault, not truncation.
file A: install.dmg (source, 314,572,800 bytes)
file B: install.dmg (from USB, 314,572,800 bytes)
integrity-report.json:
{
"fileA": { "name": "install.dmg", "size": 314572800, "sha256": "7d865e95...4e2a" },
"fileB": { "name": "install.dmg", "size": 314572800, "sha256": "83214a9c...11df" },
"identical": false,
"firstDiffOffset": 167772160,
"firstDiffHex": {
"a": "deadbeefcafebabe0011223344556677",
"b": "deadbeefcafe00000000223344556677"
}
}
Deep mid-file diff, same size -> bad-block write. Re-copy; suspect the drive.Send a digest ahead of a one-way transfer
You are pushing a file to a system you cannot pull back from. Compute the source digest with the fingerprinter, send it alongside, and the receiving party fingerprints their copy and compares.
Sender - run /security-tools/multi-hash-fingerprinter on the source: payload.bin sha-256: 5f4dcc3b5aa765d61d8327deb882cf99... Send payload.bin plus that digest. Receiver - fingerprint the received copy: payload.bin sha-256: 5f4dcc3b5aa765d61d8327deb882cf99... Compare: digests match -> transfer intact. (If both ends are on one machine, drop both files here to also get the exact corruption offset on any mismatch.)
Edge cases and what actually happens
Received copy matches the source exactly
IdenticalThe SHA-256 digests are equal, so the report returns identical: true, firstDiffOffset: -1, and firstDiffHex: null. No byte scan runs — the match alone proves the file landed byte-for-byte. Sign off the transfer.
FTP client rewrote line endings (ASCII mode)
DifferentA client in text/ASCII mode converts CRLF to LF (or vice versa), changing bytes and usually the size. The digests differ; firstDiffOffset lands at the first affected line break and the hex window shows 0d0a on one side and 0a on the other. Re-transfer in binary mode to preserve every byte.
Transfer was cut off (received copy is a clean prefix)
By designIf the received copy matches the source for its whole length and then ends, the scan runs out of bytes in the shorter file. firstDiffOffset is the received file's byte length and its hex window is empty. This is a truncated transfer — re-send and confirm the full file completed.
Same size but bytes differ (dropped bytes / bad block)
DifferentEqual sizes never prove identical content. A dropped byte on a link or a USB bad-block write can corrupt content without changing length; the tool compares digests, not sizes, so it is caught and firstDiffOffset points to the fault. A deep, same-size divergence indicates corruption rather than truncation.
A transferred file exceeds your plan's per-file limit
RejectedEach file is checked against your plan's security size cap before hashing. A 1 GB disk image on Pro (100 MB) or Pro-media (500 MB) fails with a message naming the file, its size, and the cap. Large transfers 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 fault is near the end of the file, the window simply returns fewer than 16 bytes. The firstDiffOffset is still exact; only the preview length shrinks.
Both ends are not on the same machine
Out of scopeThis tool compares two files dropped into one tab; it cannot reach across systems. For a one-way transfer, compute the source's digest with multi-hash-fingerprinter, send it alongside the file, and have the receiver fingerprint their copy and compare. Where both copies sit on one machine, drop them here for the exact offset too.
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 received copy compared against a non-empty source differs at offset 0 — the empty file is a zero-length prefix — which would signal the transfer delivered nothing.
A large file makes the tab slow
ExpectedBoth files are read fully into memory before hashing — there is no background streaming. Comparing two near-2 GB files 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 transfers.
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 one end of a transfer on its own, use multi-hash-fingerprinter.
Frequently asked questions
My transfer tool said SUCCESS — why check it again?
A transfer tool only knows it sent bytes, not that the right bytes landed. ASCII-mode FTP rewrites, botched S3 multipart assembly, USB bad blocks, and dropped bytes on a flaky link all produce a 'successful' transfer that corrupted the file. This tool compares the source and the received copy by SHA-256 and certifies they are byte-for-byte identical.
Are my files uploaded anywhere to verify the transfer?
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 re-uploaded, so files moved between sensitive systems are never sent to a third party to be checked.
Which hash does it use to verify the transfer?
SHA-256. The source and the received copy are each hashed with SHA-256 in parallel and the two 64-character hex digests are compared. A match means they are byte-identical; SHA-256 is collision-resistant for practical integrity verification.
How do I tell an ASCII-mode FTP rewrite from real corruption?
Inspect the hex window at firstDiffOffset. An ASCII-mode rewrite shows line-ending bytes diverging — 0d0a on one side and 0a on the other — and usually a size difference proportional to the number of line breaks. Re-transfer in binary mode. A scattered mid-file divergence with the same size points instead to dropped bytes or a bad-block write.
How do I know if the transfer was just cut off?
Check firstDiffOffset. If it equals the received file's byte size, the received copy is an exact prefix of the source and then ends — a truncated transfer. Re-send and confirm the full file completed. If the offset is mid-file with matching sizes, the fault is corruption, not truncation.
Can I verify a transfer when the two ends are on different machines?
Not in one step — this tool compares two files in a single tab. For a remote transfer, compute the source's SHA-256 with multi-hash-fingerprinter, send that digest with the file, and have the receiver fingerprint their copy and compare the values. If both copies end up on one machine, drop them here to also get the exact offset on any mismatch.
Does it work for any file type, including binaries?
Yes. The comparison is purely byte-level, so it treats every type the same — datasets, executables, disk images, archives, media. There is no parsing; it only compares raw bytes, which is exactly what a transfer must preserve.
How big a file can I verify?
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 transfers use a lot of RAM and take a moment to hash.
Does the filename affect the comparison?
No. Only bytes are hashed; filenames are recorded in the report verbatim but never affect the verdict. A source and a received copy with different names still report identical: true if their bytes match.
Should I encrypt a file before transferring it?
That is a separate step this tool does not do, but the sibling aes-256-encryptor encrypts a file with AES-GCM-256 and PBKDF2 before transfer. Encrypt first, then transfer, then verify the received ciphertext here against your source ciphertext.
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. You always compare exactly two files, so the per-file size cap is the limit that matters for large transfers.
What do I keep as proof a transfer was verified?
Download integrity-report.json and attach it to your transfer log or handover sign-off. It records both filenames, sizes, full SHA-256 digests, the identical flag, the first-diff offset and hex windows — proof the moved file matched the source at the time of the check. For a digest to send ahead of a transfer, use 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.