What a text diff checker does, and how this one works
A diff tool answers a deceptively simple question: what exactly changed between these two versions? For a one-line edit you can see it by eye, but across hundreds of lines of code or several pages of prose the changes hide in plain sight. This checker reads both inputs, finds the parts they share, and then shows only the insertions and deletions needed to turn the original into the modified version.
Rather than comparing line 1 to line 1, line 2 to line 2 and so on — a naive approach where a
single inserted line at the top makes everything below look changed — it computes the
longest common subsequence (LCS). The LCS is the longest run of lines (or
words) that appears in both texts in the same order. Everything inside the LCS is unchanged;
everything outside it is an addition or a removal. This is the same family of algorithm that
powers git diff and the classic Unix diff command.
A worked example
Suppose the original is alpha / beta / gamma (three lines) and the modified text
is alpha / delta / gamma. The tool keeps alpha and
gamma as the common subsequence, marks beta as removed
(−) and delta as added (+). You get a clean,
minimal description of the edit instead of three "changed" lines.
Choosing the right granularity
| Mode | How it splits text | Best for |
|---|---|---|
| Line by line | Each line is one unit; line breaks are significant. | Source code, JSON or YAML configs, logs, CSV data. |
| Word by word | Splits on whitespace so edits inside a sentence are visible. | Articles, essays, translations, legal contracts. |
The two toggles refine this further. Ignore case treats
Server and server as identical, and ignore
whitespace stops stray leading or trailing spaces from registering as a change — handy
when one file was reformatted by an editor.
<script> is escaped and
shown as literal text, never executed.