Compare Text – Diff Viewer
Paste two versions and see instantly what changed: additions in green, removals in red, and within changed lines the exact words that differ are marked as well. By line, by word or by character, as you prefer. Everything runs locally in your browser.
Result
Paste a text on the left and on the right to compare them.
Both texts stay in your browser – there is no server that could receive them.
Lines, words or characters – which granularity when?
The choice of comparison unit determines what the result looks like, and it is the most common reason for an unusable diff:
| Granularity | Good for | Weakness |
|---|---|---|
| Lines | Source code, config files, logs, CSV – anything with a fixed line structure | A changed line counts as changed in full (this tool additionally highlights the words inside it) |
| Words | Prose, documentation, translations, paragraphs without hard line breaks | Reordered paragraphs quickly turn into a confusing patchwork |
| Characters | Short strings, hashes, IDs, columns of numbers, hunting for typos | Too fine for longer texts – almost every position ends up marked |
For source code, line mode is nearly always right, because programming languages are organised around lines and git diff works the same way. For prose, however, line mode means a single changed word marks an entire paragraph as changed – word mode is the better choice there.
How the comparison works
Under the hood runs the Myers algorithm from the paper “An O(ND) Difference Algorithm and Its Variations” (Eugene W. Myers, 1986) – the same approach used bygit diff and GNU diff. It does not look for just any sequence of insertions and deletions turning one text into the other, but for the shortest possibleone. That matters, because it is exactly the presentation a human expects to see as “the change”.
The effort grows with the number of differences (the D in the name), not with the length of the text. Two nearly identical files of ten thousand lines are therefore compared instantly, while two completely different texts take considerably more work. On top of that the common prefix and suffix are trimmed up front – for a change in the middle of a long file, only the changed region is left to examine.
Ignoring case and whitespace
Both switches change only the comparison, never the display: what you see is always the original text, and only the equality test sees a normalised version. “Ignore whitespace” collapses runs of spaces and tabs into a single one and strips them from the start and end of each line. That is the switch you want when a file was converted between tabs and spaces or re-indented, and every line would otherwise count as changed.
Side by side or unified?
The side-by-side view puts both versions in two columns – good for actuallyreading two versions against each other. The unified view matches the format used by git diff and patch files: removed lines with −, added lines with +, all in one column. It is the clearer choice on narrow screens and with very long lines.
Frequently asked questions
Are my texts uploaded anywhere?
No. The entire comparison is JavaScript running in your browser – there is no server that could receive anything. That is precisely the difference from many other diff services, which send your text to a server to compare it. The only things remembered are your settings (granularity, view, switches), never the texts you compared.
Can I compare source code with it?
Yes – line mode is made for exactly that. There is deliberately no syntax highlighting, so that the colour marks for the changes stay unambiguous instead of competing with language colouring.
What does “… 12 unchanged lines” mean?
With collapsing enabled, longer unchanged stretches are folded together and only three lines of context around each change are shown – the same principle as git diff. Unticking “Collapse unchanged lines” brings the full text back.
Why does the tool give up on very large texts?
Two texts that are both long and completely different make the search effort grow quadratically – without a limit the browser tab would simply freeze. Rather than allowing that, there is an upper bound and a clear message suggesting a coarser granularity.
Related: the formatter indents JSON, YAML, TOML and XML consistently – two differently formatted files become far more meaningful to compare afterwards.