File A
Drop file A here
or click to browse — any file type, any size
File B
Drop file B here
or click to browse — any file type, any size
Choose a file for both slots, then compare.
Drop in two firmware builds, two disk images or two config dumps — byte-level comparison, entirely in your browser.
Your files never leave your browser — all processing is local.
Drop file A here
or click to browse — any file type, any size
Drop file B here
or click to browse — any file type, any size
Two firmware builds that should be byte-identical, and are not. A file that arrived over a flaky transfer, next to the original it was supposed to match. A config blob dumped before and after the device wrote to it. In all three cases the question is the same one a checksum refuses to answer: which bytes changed, and where. Drop both files in and you get the offset of every difference, how long each differing run is, and the bytes themselves side by side — so 0x1F40 becomes a place you can go and look at instead of just a hash that failed.
Nothing is uploaded, and that decides more here than on most pages. The files people actually want to diff are unreleased firmware images, customer data dumps, and the disk image off a machine that misbehaved; a site that asks you to hand over both build artefacts is asking for exactly the two things nobody is allowed to send. This page is a static file, the comparison runs in a Web Worker on your machine, and both files are read straight off disk through the File API. There is no server behind the page to send them to, so a browser-only binary diff is a genuinely different offer from any upload-based one.
Large files are handled by not reading most of them. Both files are hashed in chunks first, and chunks whose hashes agree are known to be identical without ever being compared byte by byte; only the regions that disagree get read in detail. Comparing two 500 MB images therefore does not mean pulling a gigabyte into memory, and two builds that differ in one embedded version string finish in roughly the time it takes to read the disk. The dual-pane view is virtualised the same way the hex editor is — it builds the rows currently on screen and nothing else — so scrolling a 2 GB image stays smooth.
Be clear about what a byte-level diff is not: it is not a text diff, and it does not try to realign. Insert one byte near the start of a file and every byte after it shifts by one, so the tool will honestly report that nearly the whole file differs — correct at the byte level, useless as a description of what you did. There is no alignment magic here, and pretending otherwise would just make the output untrustworthy. What it does report stays useful: a similarity percentage over compared byte positions, a segment list you can click to jump straight to any differing run, and two synced panes sharing the hex editor's offset/hex/ASCII layout, so a "shifted but otherwise identical" file is something you can see rather than something a number hides.
No. Both files are opened locally with the File API and read in chunks with Blob.slice(); the hashing and the byte comparison happen in a Web Worker inside your browser. The page itself is a static file with no API behind it, so there is nothing to upload to even in principle. That is the point of the tool: firmware you have not shipped yet and a customer's corrupted database are the two kinds of file people most need to diff and least want to put on someone else's server.
Because a byte-level diff compares position 0 with position 0, position 1 with position 1, and so on. Insert a byte at offset 16 and every byte from 16 onward moves one position along, so from that offset down almost nothing lines up and the tool reports a difference that runs to the end of the file. It is telling the truth — those byte positions really do hold different values — it just isn't the answer a human wants, because a human calls that a one-byte edit. If the files are text-like, a line-based diff is the right tool. If they are binary, look at the offset where the differences begin: that is where the insertion happened, and it is usually the fact you were after.
The overlapping part is compared byte for byte, and the tail that only one file has is reported as a trailing difference with its offset and length, not silently dropped. The similarity percentage is measured against the longer file, so appending 1 MB to a 1 MB file scores about 50% rather than 100% — appended data is a real difference, and scoring it as a perfect match would be the more misleading choice. A length mismatch is called out on its own, because for two builds of the same firmware it is often the first thing worth knowing.
Large enough that disk speed, not memory, is the limit. Neither file is loaded whole: chunk hashes locate the regions that differ, only those regions are read for detailed comparison, and the hex panes render just the rows on screen. Hundreds of megabytes per side is routine, and multi-gigabyte disk images work — the first pass has to stream both files past the hash, so it takes as long as your disk needs to deliver them. Browser tabs do have a memory ceiling, which is exactly why nothing here tries to hold a whole image at once.
Yes. Each pane carries the same offset, hex and ASCII columns as the hex editor, and the highlight covers both the hex bytes and their ASCII counterparts, so a change inside an embedded string or a file path reads as text right where it happens. It is often the fastest way to identify a diff you already suspected: a build timestamp, a version number or a serial number shows up as legible characters in the ASCII column while the hex column just shows the bytes that moved.
The fraction of byte positions that hold the same value, measured over the length of the longer file — nothing cleverer, so it is easy to reason about and easy to mislead yourself with. Two unrelated files of the same length will still land near 0.4% purely by chance, because any two random bytes match once in 256. A file with one byte inserted at the front can score in the low single digits despite being almost the same data. Read it as a quick sanity check next to the segment list — 99.98% with three short segments is a patched string, 6% is a different file — and read the offsets when you want the actual answer.