Text Diff Checker

Two versions of the same thing and no memory of what moved between them is a common and genuinely tedious problem. A contract came back from the other side's lawyer. A colleague sent a config file that works on their machine. A page of copy was rewritten and you have been asked to approve only the changes.

Reading both versions side by side does not scale past about twenty lines, because the eye is very good at seeing that two paragraphs are similar and very bad at spotting the one word that is not. This tool does the comparison properly: it works out the longest run of lines the two texts still share, marks everything else as added or removed, and then goes back into each changed line to show which words moved.

Nothing leaves the browser. The two documents people most often need to compare are contracts and source code, and neither has any business being uploaded to a stranger's server to answer a question this mechanical.

Comparing line one against line one, line two against line two and so on falls apart the instant anything is inserted. Add a single sentence to the top of a document and every line below it has shifted by one, so a positional comparison reports the entire rest of the file as changed. The one thing you wanted to see is buried in noise.

The right question is not 'is line five the same as line five' but 'what is the longest sequence of lines these two texts still have in common'. Everything in that sequence is unchanged; everything else was added or removed. That is a longest common subsequence, and it is what diff, Git and every code review tool compute.

The consequence you can see on screen is that inserting a paragraph shows as one addition rather than a rewrite of the document, and moving a line shows as a removal in one place and an addition in another.

When a removed line and an added line clearly correspond — they still share most of their words — the same comparison is run again over the words, and only the words that actually differ are marked. Changing '45 minutes' to '60 minutes' highlights two words rather than lighting up the whole sentence.

When the two lines share almost nothing, no word highlighting is shown. That is deliberate. A rewritten sentence that happens to reuse 'the' and 'and' is not an edit of the old one, and marking those few words as retained produces confetti that hides where the real change is. The threshold is about a third of the line's characters.

The marks are real ins and del elements, underlined and struck through as well as coloured, so the change survives being read by a screen reader, printed in black and white, or looked at by someone who does not distinguish red from green.

The classic algorithm needs a table with one cell per pair of lines. Two five-thousand-line files is twenty-five million cells, which as a table of numbers is around a hundred megabytes of memory — spent to recover an answer that is usually a few dozen lines long. That allocation is why so many in-browser diff tools freeze on a real file.

This one uses Hirschberg's variant, which finds the same optimal answer while only ever holding two rows of that table, so memory stays proportional to the number of lines rather than to their product. Matching lines at the start and end are set aside before any of it begins, which is what makes two revisions of one document almost instant.

There are still limits, and they are stated rather than hidden: a million characters or thirty thousand lines per side. If the changed region between the matching start and end is still enormous, the comparison is split at lines that occur exactly once in each text — unambiguous landmarks — and solved exactly between them. When even that is impossible, because the two texts genuinely share nothing, the tool says so instead of appearing to think for a minute.

Ignore whitespace trims each line and collapses runs of spaces and tabs to one. It is the setting to reach for when a file has been reformatted, when an editor has converted tabs to spaces, or when a document has travelled between Windows and Unix and come back with different line endings. Without it, a file that changed only its indentation reports as entirely rewritten and the one real change is lost in it.

Leave it off for anything where whitespace carries meaning. Python indentation, YAML nesting, Markdown code blocks and fixed-width data all change meaning when their spacing does, and a diff that hides that is worse than no diff. The same judgement applies to case: ignore it when comparing prose that has been through a style pass, keep it when comparing anything a machine will read.