Compare two text files. See the words that 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 & FAQA diff that paints a whole line red tells you something changed on it. This one tells you what: an edited line is paired opposite the line it replaced — not shown as an unrelated deletion and insertion further apart — and inside that pair the words that actually moved are marked. You find the line at a glance and the edit without reading.
Most of the noise in a real diff is not a change anyone meant. Ignore whitespace collapses runs of spaces and tabs and drops leading and trailing space, so a re‑indentation or a converted tab stops being a difference. Ignore case makes a capitalisation pass disappear. Ignore blank lines holds blank lines out of the comparison entirely, so added spacing is not reported as an edit. All three change only what counts as a difference — every row still shows the real bytes of the file, indentation and all.
The split view is the one to read. The unified toggle gives the
same comparison as the single +/- stream that
git diff produces and that code review expects. And the patch is
real: a unified diff with ---/+++ headers, proper
@@ hunk ranges, three lines of context and overlapping hunks
merged, which git apply and patch will accept. Copy
it, or download it as a .patch.
Press j and k (or n and p) to walk the changes — a run of consecutive changed lines counts as one stop, because jumping through a diff means “take me to the next edit”, not “the next line”, and a counter beside the arrows says which of them you are on. For two files of any size, or two that are not text at all, the BIN tab compares raw bytes.
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.