Comparing two versions of the same text by eye — a draft before and after edits, two versions of a paragraph, a config file before and after a change — is slow and genuinely error-prone once the text runs more than a few lines; small changes hide easily inside otherwise-identical blocks. This tool computes the difference directly, line by line, and shows exactly what was added, removed, and left untouched.
How line-based diffing actually works
At the core of this tool, and of virtually every text-diffing tool in common use, is an algorithm for finding the longest common subsequence (LCS) between two sequences — in this case, two sequences of lines. The idea is to find the longest possible run of lines that appears, in the same relative order, in both the original and the changed text, even if other lines are interspersed between them in either version. Everything in that longest common run gets marked as unchanged; everything else — lines from the original that don't appear in that shared sequence, and lines from the new version that don't either — gets marked as removed or added, respectively. This is computed with a dynamic-programming approach: building a table that tracks, for every possible pair of positions in the two texts, the length of the longest common subsequence achievable from that point onward, then walking back through that table to reconstruct the actual sequence of matches, additions, and removals. It's the same fundamental algorithm underlying git diff, the classic Unix diff command, and essentially every "compare two files" feature in modern software — not a simplified approximation of it, but the real thing, just running entirely inside your browser instead of on a server or in a terminal.
Why line-level granularity is the right default, even though it isn't perfect
Diffing can happen at several different levels of granularity — character by character, word by word, or line by line — and each has real tradeoffs. Character-level diffing is the most precise, catching even a single added or removed letter, but it produces output that's genuinely hard to read for anything beyond a very short string, since a single word change can fragment into a confusing scatter of tiny character-level edits. Word-level diffing is a reasonable middle ground, useful specifically for comparing prose where you want to see exactly which words changed within an otherwise-similar sentence. Line-level diffing, which is what this tool uses, sacrifices that fine-grained precision — a one-character edit inside a line shows as the entire line being replaced — in exchange for output that maps naturally onto how most text is actually structured and edited: a changed line in a source file, a changed line in a configuration, a changed step in a list of instructions, a changed sentence in a paragraph broken across separate lines. This is exactly why virtually every code-review tool and version control system defaults to line-level diffing rather than character-level: for the vast majority of real edits, "this line changed" is both accurate and immediately actionable in a way "these fourteen scattered characters changed" usually isn't.
What "added" and "removed" actually mean here
It's worth being precise about the vocabulary, because it matters for reading the output correctly. A line marked "removed" existed in the original text and doesn't appear (in that same relative position within the matched sequence) in the changed text — it was either deleted outright, or replaced by a different line that happens to occupy roughly the same position. A line marked "added" is the mirror image: it exists in the changed text but not in the original. When you see a removed line immediately followed by an added line, that's the diff's way of representing what a human would naturally call "this line was edited" — the algorithm doesn't have a distinct concept of "modified," only "removed from one side, added on the other," but a remove-then-add pair sitting adjacent to each other in the output is functionally the same information, just expressed as two operations instead of one.
Practical situations this tool handles well
Comparing two drafts of the same piece of writing — an essay, a blog post, documentation — to see exactly what changed between revisions, which is far faster and far more reliable than reading both versions side by side and trying to spot differences by eye, especially in longer pieces where a change buried in paragraph six is easy to miss entirely. Reviewing a configuration file before and after an edit, to confirm exactly which settings changed and catch any accidental modification to a line that wasn't supposed to be touched. Comparing two versions of a list — a set of instructions, a checklist, a set of requirements — to see which items were added, removed, or reworded between versions. Checking a piece of AI-generated or heavily-edited text against an earlier draft to understand exactly how much, and which specific parts, actually changed, rather than re-reading both versions in full to judge that by eye.
The known limitation worth understanding: moved content
Because the underlying algorithm looks for a common sequence in matching relative order, it has a specific, well-understood blind spot: if a block of unchanged text gets moved to a different position in the document — a paragraph relocated from the end to the beginning, a list item reordered — without any of its own content actually changing, the diff generally can't recognize that as "the same content, relocated." Instead, it typically shows the moved block as removed from its original position and separately added at its new one, even though not a single character within that block actually changed. This isn't a bug specific to this tool; it's an inherent limitation of line-based LCS diffing in general, and solving it properly (detecting genuine block moves as a distinct operation) requires meaningfully more sophisticated algorithms than most diff tools, including many production-grade ones, actually implement. If a comparison shows a large block as both fully removed and fully added in roughly the same content, moved-not-changed is the most likely explanation.
This tool compares lines exactly as typed — a trailing space, a tab instead of spaces, or different line-ending characters all make two otherwise-identical-looking lines register as different. If a comparison shows more changes than you expected for text that looks visually identical, invisible whitespace differences are a very common, very easy-to-miss cause worth checking for.