Drop two files and this page compares them byte by byte, right inside
your browser: every differing offset, a hex diff with surrounding context, a
difference density map, and a bit-level analysis that shows which bits
changed. A separate block-aligned mode detects insertions and deletions
in the middle of a file — the case a plain byte diff cannot align.
Results export to TXT and CSV. Nothing is uploaded anywhere.
For editing bytes instead of comparing, see the
; for text, the
Text Diff tool.
1. Pick two files
FILE A Drop the first file here, or click to choose Up to 200 MB. Stays on this machine.
FILE B Drop the second file here, or click to choose Compared against File A.
Hex context around each difference:
— neighboring differences closer than 16 bytes are shown as one block.
2. Verdict
The comparison summary appears here once both files are picked and compared.
Difference density (red: differing bytes, orange: bytes only one file has):
0x0
Bit-level analysis — which bit positions changed (of every differing byte, A XOR B):
3. Differences — hex view
| red = File A, green = File B, identical rows printed once
A byte-by-byte diff aligns offset N with offset N. If bytes were inserted or deleted
in the middle of one file, everything after that point shifts and the plain diff
reports the whole tail as different. This mode hashes 1 KB blocks, matches them
between the files and reports the result as copy / insert / delete operations —
the way delta tools such as xdelta see a change. Available when both files
are 64 MB or smaller.
5. Export
Privacy: both files are read with the browser's own FileReader
and compared in this tab — no server, no upload, no storage. Large files are compared
in 1 MB slices, so even 200 MB inputs never sit fully in memory at once (unless
you run the block-aligned view, which loads both files while it works).
What is binary file comparison?
A binary comparison lines two files up at byte 0 and walks forward,
reporting every offset where the bytes differ — the browser equivalent of
the classic cmp -l command. Text diff tools cannot do this: they
either choke on non-printable bytes or silently reinterpret the file in some
character encoding. A binary compare treats both files as exactly what they
are, arrays of bytes, which is what you want for firmware images, disk dumps,
database files, encrypted blobs or any file whose format you do not know.
Three questions get answered at three different depths. “Are they
the same?” is a checksum question — the
tool answers it fastest, but
only yes or no. “Where do they differ?” is the byte diff on
this page: offsets, values, and which bits flipped. “What kind of
change is it?” is what the block-aligned view adds — whether the
difference is an in-place edit, an inserted chunk or a deleted chunk.
Byte diff vs. block alignment — why two views?
Situation
Byte-by-byte diff says
Block-aligned view says
A field was overwritten in place (same file size)
a few scattered differing offsets
same, plus “everything else copies over”
1 KB was inserted at offset 2000 of file B
everything from 2000 on “differs”
copy 0–2000, insert 1 KB, copy the rest
A block was deleted in the middle of file B
everything from that point on “differs”
copy up to the gap, delete N bytes, copy the rest
File B is file A with a different header prepended
entire files “differ”
delete header, then one long copy — i.e. a constant shift
The byte diff is always correct — those bytes really do differ at
those offsets. It is the interpretation that shifts once bytes were
inserted or deleted, exactly like adding a line at the top of a text file
makes every following line number change.
How the bit-level analysis reads
For every differing byte the page computes A XOR B and counts
which bit positions are set. That histogram is surprisingly expressive:
differences concentrated in bit 0 (the least significant bit of every
byte) are the fingerprint of LSB steganography, where a message is
hidden by nudging the low bit of pixel or audio samples. Differences spread
evenly over all eight positions mean whole values were rewritten. Differences
that only touch high bits usually mean one field was replaced with a value
of very different magnitude. The Hamming distance (total count of
flipped bits) quantifies the same thing in one number.
One honest caveat: random data coincides at any given byte with probability
1/256, so two unrelated files of the same size still match on about 0.4% of
bytes. A similarity of 99.98% with a handful of short difference blocks is a
patch-level change; a similarity of 0.4% means the files are simply
unrelated.
Common mistakes
“The whole file is red after the first difference.” —
that is the shifting effect described above, not real corruption. Run the
block-aligned view: if it reports one insertion and two long copy operations,
the files differ by exactly that inserted chunk. “The checksums
matched but the files differ here.” — if SHA-256 digests match,
the files do not differ; re-check that you opened the same files on both
tools. A CRC-32 match, on the other hand, proves nothing against a deliberate
collision. “Similarity 0.4%, but I only changed one thing.”
— if your edit was inside a compressed or encrypted container (ZIP,
PNG zTXt, encrypted volume), one logical change rewrites the whole compressed
stream.
FAQ
What is the size limit? — 200 MB per file for the byte diff,
compared in 1 MB slices. The block-aligned view loads both files, so it is
limited to 64 MB per side. Does it detect moved chunks? — the aligner matches blocks in
order; a chunk moved to a different position shows up as a delete plus an
insert of the same content, which is a correct, if slightly blunt,
description. Can it produce a patch file? — no, it is an analysis tool; the
CSV and TXT reports are for documentation and review, not for applying
changes. What happens to my files? — nothing: no server, no storage, no
analytics; close the tab and every byte of input is gone.