Text Diff Checker

What does the Text Diff Checker do?

The Text Diff Checker takes two pieces of text — an original and a revised version — and shows you exactly what changed. Lines that were added show in green. Lines that were removed show in red. Lines that changed in place show with the old version struck through and the new version highlighted. Paste both sides, look at the output, see every edit at a glance.

Most of the time, you already know something changed — a colleague sent back a contract, a teammate revised a paragraph, an AI rewrote a draft. The question is what. Eyeballing two paragraphs side-by-side and trying to find a one-word swap takes minutes and you'll still miss things. The diff checker does it in a quarter of a second.

This is the same kind of comparison git diff shows for code, but applied to plain prose, contracts, log lines, translations, and anything else where two versions exist and you need to know what moved between them.

When you'll reach for it

Diff comparisons come up in more places than people realize. The most common cases:

• Contract revisions. A counterparty returns a Word doc with their proposed edits. Track Changes is supposed to handle this, but half the time it's been turned off, accepted-all, or applied inconsistently. Paste the original and the redline side by side; every edit appears.
• Proofreading and editing. A copy editor returns your draft. Instead of reading both versions line-by-line, you diff them and review only the lines that actually changed.
• Log line comparison. Two server runs produced slightly different output. Which lines drifted? The diff finds the three lines out of three thousand that aren't identical.
• Translation review. A translator returns a new locale file. Drop the old version on the left, the new version on the right; every changed string is highlighted.
• AI output comparison. You ran the same prompt twice and got two different drafts. Diff them to see exactly where the model wandered.
• Configuration file audits. Two YAML or JSON files that should be identical aren't. The diff shows the difference in seconds. For structural JSON comparison, JSON Diff is a better fit — it ignores key order — but for line-level changes, this works.
• Email and message review. A team member edited a customer reply you drafted. What did they change? Paste both, see the edits.
• Document version archeology. You find an old version of a doc and a recent one. What happened between them? The diff is the answer.

The common thread: anywhere two versions of plain text exist and a human needs to know what changed without reading every word. The tool collapses minutes of careful comparison into one paste.

How the diff works (the LCS algorithm)

The Text Diff Checker uses an algorithm called Longest Common Subsequence, or LCS. Here's the idea in one paragraph.

Given two sequences of text, LCS finds the longest run of items that appears in both, in the same order. Anything that's in the longest common subsequence is "unchanged." Anything in the original but not in the common subsequence is "removed." Anything in the revised but not in the common subsequence is "added." Run the algorithm once, and you have a complete diff.

The LCS approach is the same idea behind git diff, the Unix diff command, and the diff views in GitHub, GitLab, and most code editors. It's been the standard algorithm since the 1970s because it produces minimal, human-readable diffs — the smallest set of edits that explains how one version became the other.

The tool runs the algorithm entirely in your browser, in JavaScript. Nothing about your text is sent anywhere. Both sides of the diff exist only in your tab's memory, and they disappear the moment you close it. That makes the tool safe for confidential drafts, internal contracts, customer messages, and anything you wouldn't paste into a third-party server.

Worked example: a one-line contract edit

Let's run a small but realistic example. Two paragraphs from a freelance contract — one is your draft, one is what the client sent back.

To the eye, those paragraphs look almost identical. The diff output makes the changes obvious:

• Line 1, word level: "within 30 45 days of the project kickoff" — the delivery window doubled from 30 to 45 days.
• Line 2, word level: "issued within 14 30 days of acceptance" — the payment window also stretched, from 14 to 30 days.
• Line 3: unchanged — the termination clause is identical.

Two changes, both numeric, both meaningful: the client wants more time to receive the work and more time to pay for it. If you had eyeballed those two paragraphs without the diff, you might have caught the 30-to-45 swap but missed the 14-to-30 — and you'd be agreeing to wait twice as long for your money without realizing it. That's the kind of moment the tool exists for.

Three granularities: line, word, and character

Diffs come in three flavors, depending on how finely you want to slice the change. Each is the right choice in different situations.

For most prose comparisons, word-level is the sweet spot. Line-level over-reports — a one-word swap looks like a full-line rewrite. Character-level under-reports the semantic change — you see that "r" became "R", but you have to mentally reassemble the word. Word-level shows the units you read in, which makes the diff scan naturally.

The exception is code or structured data. For source files and configs, line-level is the convention because lines have meaning of their own (a function signature, a config key, a JSON property). That's what GitHub, GitLab, and git diff default to. For prose, switch to word-level.

How to read the output

The display follows the convention most developers will already know:

• Green / + means added in the revised version — content that exists on the right but not on the left.
• Red / − means removed from the original — content that exists on the left but not on the right.
• Unchanged lines appear in neutral text, often grayed out, so your eye skips them and lands on the real changes.
• Changed-in-place lines show both versions: the old struck through, the new highlighted. Word-level mode does this within a single line; line-level mode shows the whole old line removed and the whole new line added on separate rows.

If the diff shows "Identical" or 0 changes, both texts are the same character-for-character, including whitespace. If the diff shows changes you didn't expect — especially at the start or end of paragraphs — the most common cause is trailing whitespace, line-ending differences (Windows \r\n vs. Unix \n), or invisible characters that snuck in via a paste from Word or Google Docs.

A few patterns worth knowing

Some quirks of the LCS algorithm catch first-time users off guard:

• Inserting a line at the top shifts everything below. If you add a single paragraph at the start of a document, the diff sees the new paragraph as added — but it also potentially sees every paragraph below it as moved, depending on whether the algorithm finds the longer match by keeping the old content in place. Modern LCS implementations handle this well, but very long documents with structural reordering can produce diffs that look messier than they should.
• Reordering doesn't produce a "moved" marker. If you swap paragraph 3 with paragraph 5, the diff shows two pairs of "removed" and "added" rather than a single "moved" marker. LCS has no concept of identity-across-positions — it only finds matching subsequences in order.
• Identical lines that appear in different places. If the line "Yours sincerely," appears in both texts but in different positions, LCS may or may not match them as the same line, depending on what gives the longest overall match. This is rarely an issue in practice but can show up in repetitive logs.
• Case sensitivity. By default, the diff is case-sensitive — Hello and hello diff as different. If you want a case-insensitive comparison (useful for log files where casing isn't meaningful), normalize both sides with the Text Case Converter first.

For comparing structured data — JSON, YAML, configs where key order shouldn't matter — the line-based diff isn't the right tool. JSON Diff parses both sides as JSON before comparing, so {"a":1,"b":2} and {"b":2, "a":1} register as identical, which a line diff would call different. Pick the diff that matches the data shape.

Related text tools

The Text Diff Checker pairs naturally with the other text-cleanup tools when you're prepping content for comparison or post-processing the result:

• JSON Diff — structural comparison for JSON files, ignores key order and whitespace. The right tool for API response comparison or config file audits.
• Text Case Converter — normalize both sides to the same case before diffing, useful when casing isn't meaningful to the comparison.
• Remove Duplicate Lines — clean both inputs before comparing, especially helpful for log files or lists with repeated entries.
• Sort Lines — order both sides identically before comparing, when the line content matters but the line order doesn't.
• Word Counter — quick way to gauge whether two drafts are even roughly the same size before diving into the diff.

Frequently asked questions

Is my text stored anywhere?

No. Both sides of the diff exist only in your browser. The LCS algorithm runs in JavaScript, locally. No server upload, no logging, no copy retained. Closing the tab clears both inputs from memory.

What's the difference between line-level, word-level, and character-level diffs?

Line-level compares whole lines; any change on a line marks the entire old line as removed and the new line as added. Word-level breaks each line into words and highlights only the words that changed. Character-level goes down to individual characters. Word-level is best for prose, line-level for code, character-level for very short text where every keystroke matters.

Why is the diff showing whitespace changes I didn't make?

The most common causes: trailing spaces at the end of lines, different line endings (Windows \r\n vs. Unix \n), invisible non-breaking spaces (often from copy-pasting out of Word or a webpage), or stray tab characters. If you only see "changes" at line boundaries, normalize whitespace on both sides before re-comparing.

Does the tool work for non-English languages?

Yes. The diff operates on Unicode characters, so it works for any language — Spanish, German, Russian, Arabic, Chinese, Japanese, Hebrew, and all others. Word-level diffs split on whitespace, which means languages without spaces between words (Chinese, Japanese, Thai) work better at character-level or line-level than at word-level.

Can I compare files instead of pasted text?

This tool is paste-based — open both files in any text editor, copy the contents into the two boxes. For very large files or programmatic comparison, command-line diff on Unix or fc on Windows is the right tool. For everything human-readable that fits in your clipboard, paste is faster.

Why does swapping two paragraphs show four changes instead of one move?

The LCS algorithm doesn't track moves — it only finds matches in order. Swapped paragraphs look like two pairs of "remove from old position, add to new position." For most prose review this is fine; the human eye can spot the swap quickly even when the diff doesn't label it. For larger structural rearrangements, expect a noisier diff than the actual change feels.

What's the largest text I can compare?

The LCS algorithm is O(n×m) where n and m are the lengths of the two inputs. For text under 100,000 characters per side, the diff is instant. Above that, it slows; multi-megabyte inputs may take a noticeable second or two. For diffing very large logs or codebases, a command-line tool is faster than a browser-based one.

How is this different from git diff?

The algorithm is the same family (LCS-based). git diff is built into git and runs over versioned files inside a repository. The Text Diff Checker does the same thing for any two pieces of text — versioned or not, code or prose, files or pasted strings. Use git diff when you're inside a repo. Use this tool when you've got two pieces of text and need to compare them without setting anything up.