Text Diff Checker

Text Diff: The Oldest Engineering Tool Still in Daily Use

Diff was invented in 1974 (Doug McIlroy at Bell Labs). Five decades later, every code review, every git commit, every configuration audit, and every contract revision still runs through it. This tool brings the diff experience to ad-hoc text comparison, paste two versions, see what changed, decide if the change is right.

The Three Granularities of Diff

Line diff is the default and what you usually want.

• Treats each line as an atomic unit.
• Adds/removes/keeps whole lines.
• Best for code (lines = statements), configs (lines = settings), CSV data (lines = records).

Word diff is for prose changes.

• Within each line, highlights which words changed.
• Useful for editorial review of an article, contract redlines, blog post versions.
• A reformatted paragraph with one word changed shows that one word, not the whole paragraph.

Character diff is the finest granularity.

• Each character is a unit.
• Useful for: 'I changed one digit in this number, where is it?' or 'is this a different email or just visually similar?'.
• Noisy for prose-level changes (every changed word becomes a sea of red and green characters).

This tool lets you switch between all three on the same paste.

How Diff Algorithms Work (Briefly)

The classic diff algorithm finds the longest common subsequence (LCS) between two sequences. Everything in the LCS is unchanged; everything outside it is an addition or deletion.

The naive LCS algorithm is O(n²), slow for large inputs. Modern diff implementations use:

• Myers algorithm (1986), O(n×d) where d is the size of the diff. Much faster when the inputs are mostly similar.
• Histogram diff (Git's default), Even better for code, where lines repeat predictably.
• Patience diff, Optimized for diffs with large rearrangements.

This tool uses Myers algorithm for line/word/character diffs. For typical text (mostly unchanged with localized edits), performance is near-instant up to ~100,000 lines.

Side-by-Side vs. Unified

Two views of the same diff:

Side-by-side:

Better for: visual scanning, small changes, comparing one screen of text.

Unified:

Better for: sharing in code reviews, pasting into commit messages, automation that parses diff output. Lines starting with - are deleted; + are added; space-prefixed are context (unchanged). This is the format git outputs.

Whitespace and Formatting Differences

A common annoyance: two files are semantically identical but formatted differently. Indentation changed, trailing whitespace added, line endings differ (CRLF vs LF). The 'ignore whitespace' option treats these as equal:

• Ignore all whitespace: lines that differ only in whitespace are considered identical.
• Ignore leading whitespace: indentation changes ignored.
• Ignore trailing whitespace: trailing spaces ignored.
• Ignore EOL differences: \r\n vs \n treated as equal.

For comparing code where one version was run through Prettier, 'ignore whitespace' is the right setting. For comparing JSON where formatting matters less than content, it's also useful.

Use Cases Beyond Code

• Contract revisions. Original and proposed redline; spot every change in legal text.
• Email drafts. Compare a sent email to a follow-up draft to see what you changed.
• Configuration audits. Compare prod and staging configs to spot drift.
• Translation review. Original and translated text side-by-side (word diff helps spot rephrasing).
• Document edits. Compare two versions of a Word doc exported to plain text.
• API response comparison. Compare two API responses to find what changed between calls.
• Log analysis. Compare two log excerpts to spot new error patterns.

Limitations and Edge Cases

• Reordered content. Diff doesn't handle 'these two paragraphs were swapped' well, it shows both as deletions+additions. Algorithms exist for this (XML-aware diffs, JSON diffs) but are specialized.
• Binary content. Diff is for text. For binary (images, PDFs), use a binary-aware comparison tool.
• Very long lines. A single 50,000-character line is treated as one line by line-diff. If that line changed in 10 places, line diff shows the whole line; word diff is more useful.
• Encoding differences. Two files that look the same but use different Unicode normalizations may show as different. This tool normalizes to NFC before comparing.

Patch Output

Some diff workflows want to produce a 'patch' file, a unified diff that can be applied with patch or git apply to transform original into modified. This tool's unified view is in standard patch format; copy it, save as .patch, apply with:

This isn't the typical use case for a browser-based diff (you have git for that), but it's possible.

Common Workflows

1. Pre-commit review. Compare your in-progress changes against the last clean version to make sure nothing accidentally crept in.
2. Vendor comparison. Compare a contract before and after vendor edits.
3. AI-generated content review. Compare a draft to AI-revised version to see all the edits.
4. Configuration drift. Diff a known-good config against the current live config.
5. Spec compliance. Diff your implementation's output against the expected spec output.
6. Translation QA. Diff two translations of the same source.

Privacy

Both inputs and the computed diff stay in your browser. The diff algorithm runs in JavaScript, the highlighting in HTML/CSS. No outbound requests. Suitable for comparing proprietary code, sensitive contracts, internal configs.

Before: The quick brown fox jumps over the lazy dog.
After:  The quick brown fox leaps over the sleepy dog.

Line:  whole line shown as deleted + whole line added
Word:  - jumps + leaps,  - lazy + sleepy   (clean)
Char:  - jum + lea, - ps + ps, ...         (noisy)

@@ -1,5 +1,5 @@
 function greet(name) {


return "Hello, " + name;


return Hello, ${name};
 }

@@ -1,5 +1,5 @@
-1,5  →  original: 5 lines starting at line 1
+1,5  →  modified: 5 lines starting at line 1

1. Line endings: CRLF (Windows) vs LF (Unix)


Trailing whitespace on otherwise-identical lines
BOM (\uFEFF) at the start of one file
Unicode normalization: é as U+00E9 vs e + U+0301

diff -u  → may show nothing

xxd a | diff - <(xxd b)  → reveals byte-level differences
cat -A file.txt  → shows ^M (CR), $ (LF), tabs as ^I