Compare two files byte for byte

How to compare two files

1. Drop one file into each panel. Order does not matter, and the files can have different names, live in different folders and carry different timestamps.
2. Let the comparison run. Both files are read side by side in 4 MB slices. SHA-256 is computed for each while the bytes are compared directly, all in a single pass.
3. Read the verdict. Identical means byte-for-byte identical contents. Different means at least one byte differs, and the panel tells you which one.
4. Copy either digest if you need to paste it into a ticket, a release note or a message.

What is compared, and what is ignored

Property	Affects the verdict?
File contents (every byte)	Yes — this is the whole comparison.
File length	Yes. Different lengths cannot be identical files.
Filename	No.
Folder or drive	No.
Created and modified timestamps	No.
Permissions and ownership	No.
Extended attributes, resource forks, alternate data streams	No — the browser cannot see them.

That last row is worth remembering on macOS and Windows: two files can be byte-identical in content while differing in metadata the browser has no access to. For ordinary use — checking whether a copy survived, whether a download matches, whether two backups diverged — content is what you care about.

Why the first differing byte is useful

Knowing that two files differ tells you little. Knowing where they first differ usually tells you why:

• Offset 0. Completely different files, or the same content in a different container format. Check the file signatures.
• A small offset, inside the header. Embedded metadata: a timestamp, a producer string, a compression level, a UUID written by the exporting application. Common with PDFs, ZIPs and images.
• Deep into the file, with a matching prefix and one file shorter. A truncated or interrupted copy. The tool reports "beyond the shorter file" when one file is an exact prefix of the other, which is the classic signature of an incomplete download.
• Deep into the file, same length. A single corrupted block, a bit flip from failing storage, or a targeted modification. Isolated damage in the middle of an otherwise matching file usually means hardware, not malice.
• Right at the very end. A trailing newline, an appended signature block, or padding added by an archiver.

Common reasons two "identical" files differ

• Line endings. A text file that has passed through Windows has CRLF where the original had LF. Every line is different at the byte level even though the content reads the same.
• A trailing newline. Editors disagree about whether the last line should end with one. One byte, completely different digest.
• Text encoding. UTF-8 with a byte-order mark versus without. Three invisible bytes at offset 0.
• Timestamps inside archives. Zipping the same directory twice produces different bytes because the entries record the moment of compression.
• Image and document metadata. EXIF, XMP and PDF producer strings change when a file is re-saved, even with no visible edit.
• Silent corruption. Rare, but real — this is precisely what checksums exist to catch.

Handling very large files

Both files are streamed rather than loaded, so peak memory stays in the low megabytes whether you are comparing two text files or two 50 GB disk images. The bottleneck is disk read speed, and the panel reports combined throughput so you can see it. Nothing is uploaded, which is what makes comparing large private files practical at all — a server-based comparison would mean transferring both files in full.

SHA-256 is computed alongside the byte comparison, so you get the digests for free. Two files with the same SHA-256 are identical for every practical purpose; the direct byte comparison is what allows the tool to pinpoint the divergence rather than just report a mismatch.

Good uses for this

• Confirming a backup or a restore is faithful before deleting the original.
• Checking that a large file copied to an external drive or NAS arrived intact.
• Deciding whether two similarly named files in your downloads folder are duplicates.
• Verifying that a build is reproducible — that the same inputs produced the same artefact.
• Checking that an export from one tool matches an export from another.
• Confirming that a file you were sent matches the copy you already had.