Picture this: a colleague messages you "hey, something broke since yesterday's deploy." They changed 400 lines across 6 files. The git diff scrolls past your terminal screen in about half a second of wall-clock time. You're supposed to figure out exactly what moved, what disappeared, and whether the change was intentional — in a diff that's longer than most short stories. This is the moment diff tools live for.
At its core, a diff is a pair of sequences ("here's what the document used to look like, here's what it looks like now") and a compact list of operations to get from one to the other. The algorithm underneath — most commonly a variant of Myers' diff algorithm, the same family Git uses — finds the longest common subsequence (the biggest chunk of text that appears in unchanged form in both versions) and labels everything else as either removed, added, or in-line-changed. The result is dramatically more compact and dramatically more useful than "dump both versions side by side and let the human compare." A diff is an answer to the question "what specifically changed?" rather than "here are two things, good luck."
This tool gives you a clean place to ask that question without firing up a terminal. Paste (or drop) your original text on the left and your modified text on the right, and the comparison refreshes live as you edit either side. A mode toggle switches between the two canonical views: side-by-side (two aligned columns, unchanged text on context lines, red/green highlights for removed/added) and inline (a single column where deletions and insertions are interleaved in document order — the format git diff --no-index produces). A word/character/line granularity toggle controls how tight the comparison runs — word-diffs catch "renamed a variable in a paragraph" that a line-diff merges into one giant "this whole line changed" block.
Color coding does the heavy visual lifting. Removed text red, added text green, and — in word-diff mode — substitutions shown as both a deletion and an adjacent addition in place, so you can see "this word became that word" in one spot rather than hunting for a red block on the left and a green block on the right. Line numbers on both panels anchor changes to positions you can quote in a code review comment ("lines 42–45, you changed the comparison operator here").
A few commonly-needed niches are toggles. "Ignore whitespace" hides indentation-only changes (common when someone runs a formatter across a file). "Ignore case" forgives the "I uppercased the heading" edits. "Ignore blank lines" removes formatting-only noise. The statistics footer shows the running count of unchanged lines, additions, deletions, and net change — a one-glance number for "was this edit 3 lines or 300?"
Export is the feature you don't think you need until you do. The unified diff output (diff -u format) drops cleanly into an email patch, a code review tool, or a git apply command. And the result URL shares a live link to the exact comparison — useful for answering "here's what changed" in a design review or a vendor-integrity check without attaching files.
Where this shows up in real work beyond the code review UI: the legal team comparing a December contract draft against January's redline and needing to surface exactly which clause number changed, a localization team verifying that a translated document has the same paragraph ordering as the source, an ops engineer tracking a configuration drift between prod and a backup by comparing two JSON blobs, a student finding out whether the professor "significantly revised" last year's exam or just renamed a section, and a support agent auditing the settings of a working vs. broken deployment by diffing two environment-variable dumps.