Text Diff (Inline & Side-by-Side)

A text diff highlights exactly what changed between two versions of a document — which words were added, which were removed, and which stayed the same. This free tool compares two blocks of text directly in your browser and shows the result inline with colour highlighting, plus a copy-ready unified diff for sharing.

The algorithm behind the highlights

The tool first splits each side into tokens. In word mode it splits on whitespace (keeping the spaces so formatting is preserved); in character mode it splits into individual characters. It then computes the longest common subsequence (LCS) between the two token lists — the longest ordered set of tokens that appears in both.

Walking that LCS table from start to finish produces three kinds of token:

• equal — present in both, shown plainly.
• remove — present only in the original, shown red and struck through.
• add — present only in the modified text, shown green.

This is the same core idea behind git diff and most code-review tools.

When to use word mode versus character mode

Word mode is the right choice for most prose work: editing a draft email, reviewing contract redlines, or checking that a translated paragraph matches the original in structure. Whole added or deleted words light up in a clean, readable way, and sentence-level rewrites show as clean blocks of red followed by green.

Character mode is better for short, dense content where a single character matters: API keys, serial numbers, regex patterns, template strings, or code identifiers where userId and useId mean very different things. It catches the transposed letter that word mode would miss because word mode treats the whole misspelled word as one token.

Worked example: contract clause revision

Original: “The contractor shall deliver all reports within thirty (30) calendar days of the project start date.”

Modified: “The contractor shall deliver all reports within fourteen (14) business days of the project start date unless otherwise agreed in writing.”

In word mode, the diff highlights:

• Removed: thirty, (30), calendar
• Added: fourteen, (14), business, unless, otherwise, agreed, in, writing

The unchanged frame — “The contractor shall deliver all reports within … days of the project start date” — stays plain, making it immediately obvious that only the deadline terms changed. This is far faster to review than reading both versions side by side.

Reading the unified diff output

The unified diff format is the standard used by Git and most patch tools:

-thirty (30) calendar days
+fourteen (14) business days unless otherwise agreed in writing

Lines starting with - were in the original only, + were added, and unchanged context lines start with a space. You can copy this output and paste it into a GitHub comment, a bug report, or save it as a .patch file that tools like git apply can consume.

Practical tips

• The summary badge showing +N added · -M removed gives you an at-a-glance measure of how much changed without reading every highlighted word.
• For very long documents, paste only the paragraph or section you care about — the LCS algorithm’s speed degrades on very large inputs.
• Newlines are treated as whitespace in word mode, so if you need line-by-line comparison of code or a list, character mode or a dedicated code-diff tool may show structure more clearly.

Where diffing comes from

The comparison approach used across the software world descends from Eugene Myers’ 1986 algorithm, An O(ND) Difference Algorithm and Its Variations — the same family of longest-common-subsequence methods that powers git diff and GNU Diffutils. The algorithm finds the minimal set of insertions and deletions transforming one sequence into the other; what varies between tools is the unit of comparison (the trade-offs are documented well in the git-diff documentation, which exposes several of these algorithms as options). Line-based diffs suit code; this tool’s word and character modes suit prose, where a one-word edit inside a long paragraph should highlight one word, not flag the entire line as changed.

Diffing in the age of AI-edited text

A newly common workflow: paste a document into an AI assistant for “light editing”, get back something that looks the same, and need to know exactly what changed. Word-mode diff is the honest audit tool here — it reveals every substituted term, deleted hedge and quietly rewritten clause. Two habits make this reliable: diff before accepting AI edits into a contract, policy or citation-bearing text, and treat any unexplained change in numbers, names, dates or negations (“may” → “must”, “not” removed) as a red flag to verify manually. The same practice applies to reviewing a colleague’s tracked-changes-free edits: paste both versions, read the highlights, and no silent change survives.

For repeated comparisons — successive drafts of the same document — a useful habit is to diff each version against the previous one rather than against the original: chains of small, reviewed diffs are far easier to audit than one cumulative comparison where hundreds of changes bury the handful that matter.

Character mode earns its keep on the smallest edits — a changed digit in an amount, a swapped letter in a name — where word mode would flag the whole token and leave you hunting for which character actually moved.