Text Diff Checker

Working out what changed between two versions of something — a contract clause, a config file, a paragraph of copy — is slow and unreliable by eye. This tool does it properly: it runs a real diff algorithm over the two texts and shows you the changes, with the original's line numbers down one side and the modified version's down the other.

"Properly" is doing some work in that sentence. The naive way to compare two texts is to line them up and check the first line against the first, the second against the second, and so on. It falls apart immediately: insert a single line at the top of a twenty-line file and everything below it shifts by one, so a comparison of that kind reports all twenty lines as replaced. A diff algorithm exists to find the longest sequence the two texts still share, which is why inserting one line here reports one added line and nineteen unchanged ones.

Changes inside a line are highlighted word by word, so a line that reports as changed also shows you which word did it — but only when the two lines are genuinely a rewrite of each other, because highlighting the differences between two unrelated lines is noise dressed up as information. You can compare by line, by word across the whole document, or character by character.

Long stretches with nothing in them collapse to a single click, so a two-thousand-line file with one edit reads in a glance instead of scrolling. And what you copy is a valid unified patch — proper hunk headers, no stray spaces after the markers — so it can be piped to patch or git apply rather than only read.

Most real comparisons are a small change in a large file, so showing every unchanged line is showing almost nothing useful. Stretches with no changes in them collapse to a single row naming how many lines it hides, with a few lines of context kept either side of each change — the amount is yours to set — and one click expands any of them. The up and down buttons step from one change to the next, which is the difference between reviewing a three-thousand-line file and scrolling through one.

The summary line counts what changed: lines added, removed, changed and unchanged, plus how similar the two texts are overall. It is the quickest way to sanity-check that you pasted what you meant to.

Copy gives you two things. "Copy patch" produces a unified diff with real hunk headers — the @@ lines that say where each change sits and how many lines it spans — which is a format other tools can consume rather than merely display. "Copy text" gives the plain reading view with plus and minus markers, for pasting into a review comment or an email. The patch can also be downloaded as a .patch file.

The question a diff answers is not "are these two lines the same" but "what is the shortest set of insertions and deletions that turns the first text into the second". Those are very different questions, and only the second one survives an edit that shifts everything below it.

The method here is Myers' algorithm, the same one Git uses. It searches for the furthest it can get through both texts using a given number of edits, increasing that number until it reaches the end of both — which finds a minimal edit script rather than the first one it stumbles on. Before it runs, the shared beginning and end of the two texts are trimmed away, because the usual case is a small change in a large file and there is no sense searching the parts that obviously match.

One consequence worth knowing: a block of text that moved is reported as deleted from one place and added in another, because that is genuinely what the shortest edit script says. Detecting a move as a move is a separate problem, and one this tool does not claim to solve.

Line endings cause more confusion than any other part of comparing text. Windows historically terminates a line with a carriage return and a line feed; Unix-derived systems use the line feed alone. A file that has crossed between them is textually identical and yet differs on every single line, which is exactly what version control's line-ending settings exist to prevent. This tool normalises both before comparing, and tells you when that was the only difference — because "these files differ only in line endings" is a useful answer, not something to hide.

Beyond that, match the comparison unit to the material. Lines suit code, configuration and logs, where a line is a meaningful unit. Words suit prose, where reflowing a paragraph moves every line break without changing a single sentence — comparing by word ignores where the lines happen to fall. Characters suit the case where one identifier or number changed and you want to see precisely which characters moved.

The ignore options handle the rest. Case, indentation, trailing spaces, all whitespace, or blank lines can each be excluded from the comparison — and excluded from the comparison only: the text on screen is always what is actually in your file, so turning on "ignore indentation" does not quietly reformat anything.