Two files, every byte, and which bits moved.
safe · secure · no server · works offline · fast
…or paste a file you copied in Finder, or just start typing at the cursor.
↓ scroll for about & FAQsafe · secure · no server · works offline · fast
…or paste a file you copied in Finder, or just start typing at the cursor.
↓ scroll for about & FAQ
The answer comes first, as a single number: what percentage of the two files
is identical, over a bar that draws the differing bytes against
the identical ones at their real weights. Then the bytes. The hex view is
stacked — an offset both files agree on prints
once, and only a differing one splits into an A row above a B row, so
you never scan two columns looking for one flipped nibble — with every
differing byte lit in the hex and in the ASCII gutter. (One click gives you the
classic side‑by‑side pair instead.) When three
hundred bytes differ in a two‑megabyte file, scrolling is not a plan, so
the view opens on the first difference and j and k (or
n and p) jump between differing regions. The one you are on
is called out from the rest: its line is banded and its bytes turn
yellow on red, with a 12 / 162 counter, because on
a screen where three hundred bytes are already lit the one you jumped to has to
say so. Underneath, a byte inspector resolves that region all
the way down — hex, decimal, the ASCII either side, the signed delta and
which bit weight moved — and a density map shows whether
the changes sit in one place or run through the whole file, clickable to go
there. Every differing region is also listed — offset, size, bits —
on a grip beside the hex: shut when you arrive, because the bytes are what you
came for, and one click wide when the list is the thing you want.
Two files can differ in the same number of bytes for completely different reasons, so this tab counts the Hamming distance — differing bits — and breaks it down by bit position. Every changed byte differing in exactly one bit, always the lowest, is least‑significant‑bit steganography: data hidden in the quietest bit of many samples, invisible in the picture and unmissable in the histogram. Bits moving across all eight planes mean whole values were rewritten. One higher plane means a single bit plane was replaced. A byte count cannot tell those apart; the bit chart can, and the tab says which it sees in plain English.
If two files differ yet are byte‑for‑byte the same length, that on its own is close to conclusive. Re‑saving a file picks its own size and essentially never reproduces the original exactly, so an identical size with a scatter of changed bytes means something was rewritten in place — a field overwritten, a compression choice swapped, a payload tucked into room the format already had. OmniViewer’s own /png/secret does precisely that, and the sample pair on this page is its output: the same image twice, identical in size and in every decoded pixel, differing in 1,877 bytes of compressed data.
Both files are read in lockstep in 4 MB blocks; each pair of blocks is folded into counters, a region list and the density map, then thrown away. Peak memory is two blocks whatever the files weigh, so two 20 GB disk images compare on a laptop. The hex view is windowed on top of that, slicing only the rows on screen out of each file. For two text files, the TXT tab gives a line diff instead.
It’s one lens on OmniViewer’s Diff Checker — Compare Two Files: drop a file and every tab is one click away. OmniViewer opens every file format, entirely in your browser — no upload, no server.
No. OmniViewer is a static page with no server-side processing. Both files are read directly by your browser and compared in a Web Worker on your own machine. Nothing is sent anywhere, which is the main reason to use it for a file you would not paste into a website — a config with credentials in it, an unreleased binary, a private document.
The binary comparison has no practical limit. Both files are streamed in lockstep in 4 MB blocks and each block is discarded once it has been counted, so peak memory is two blocks no matter how large the files are — two multi-gigabyte files compare fine. The text comparison is bounded, because line-diffing two files means holding both as text: it reads the first 16 MB of each side and tells you when it truncated. The binary tab still covers every byte of both files in that case.
It collapses runs of spaces and tabs to a single space and drops leading and trailing whitespace before comparing, so a re-indentation, a converted tab or a stray trailing space is no longer a difference. It deliberately does not remove whitespace entirely — that would make "a b" equal "ab", which is a different and wrong claim. The normalisation applies only to the comparison: every row still shows the real text of the file, indentation and all.
Yes. The TXT tab emits a real unified diff — the format git and patch read, with --- / +++ headers and @@ hunk ranges, three lines of context, and overlapping hunks merged. Copy it to the clipboard or download it as a .patch. It is generated from the same comparison you are looking at, under whichever ignore options are switched on.
It shows which of the eight bits in a byte actually changed, and how often. The shape of that chart identifies the kind of edit. Every changed byte differing in exactly one bit, always bit 0, is least-significant-bit steganography — data hidden in the quietest bit of many samples. Changes spread across all eight planes mean whole values were rewritten. A single higher plane means one bit plane was replaced. A byte count alone cannot tell those apart; a bit count can.
Almost always that one was edited in place rather than regenerated. Re-encoding or re-saving a file picks its own length and essentially never lands on exactly the original, so an identical size with differing bytes points at something rewritten inside the existing structure: a metadata field overwritten, a compression choice swapped, or a payload hidden in space the format already had. OmniViewer says so explicitly when it sees that combination.
The Myers algorithm costs time proportional to the number of differences, so it is nearly instant on two similar files and most expensive on two that share nothing. There is a work budget: past it, that region is reported as a wholesale replacement rather than spending unbounded time proving two unrelated files have nothing in common — which is the honest answer anyway.
Yes, though the useful answer will be on the BIN tab. Both tabs accept any two files: TXT decodes both as UTF-8 and line-diffs them, which is meaningful only if they really are text, while BIN compares raw bytes and works on anything. The two tabs run on the same pair, so you can switch between them without re-dropping.