Text Diff Checker
Compare two blocks of text with line and word-level highlighting, whitespace and case options, and a unified diff you can save as a patch.
Original
Changed
Differences
Paste text into both panes to compare them.
Both texts are compared in your browser — nothing is uploaded. The unified view is a real patch: save it as a .diff file and git apply will take it.
About the Text Diff Checker
Paste two blocks of text and see what changed between them, line by line and word by word. This diff checker uses the same longest-common-subsequence approach that `git diff` and every code review tool use, so an inserted paragraph is reported as an insertion rather than as a rewrite of everything below it — which is what a naive line-by-line comparison produces and why it is useless on real edits.
On top of the line diff sits a word-level one. When a line was modified rather than added or removed, the two versions are matched up and only the words that actually differ are highlighted. A changed port number in a config file, a flipped boolean, a corrected typo: all of them show as a few highlighted characters instead of two entire red and green lines you have to read twice.
The unified view is a real patch — the `---`/`+++`/`@@` format that `git apply` and `patch` accept. Copy it into a file and it will apply. That makes this useful for more than looking: you can compare two versions of a config here and hand the result to someone as a diff.
- LCS line diff, so insertions and deletions are found rather than assumed
- Word-level highlighting inside modified lines
- Line numbers from both sides, side by side
- Ignore case, whitespace or blank lines
- Unified diff export that git apply accepts
- A similarity percentage, and counts of added, removed and modified lines
How to use it
- Paste the original text on the left and the changed version on the right.
- Read the inline view: removed lines in red, added lines in green, with changed words highlighted inside them.
- Turn on Ignore whitespace if reindentation is drowning out the real changes.
- Switch to Unified for a patch, and copy it.
- Check the counts at the bottom for a quick sense of how much moved.
Real-world use cases
Backend & config engineers
Paste two versions of a YAML, .env or config file to see exactly which keys changed between environments or deploys — the word-level highlighting turns a changed port number or flipped boolean into a two-character diff instead of two full red and green lines.
Code reviewers
Compare a before/after snippet pasted from a PR description, a Slack thread or a ticket when the change isn't in a repo you have checked out locally, and export a unified patch to hand back if a proper diff is needed.
QA & test engineers
Compare expected output against actual output from a test run or a bug report, with Ignore whitespace on to strip out reindentation noise and see whether the values themselves actually differ.
Technical writers & docs engineers
Compare two revisions of a README, changelog or runbook to confirm exactly what changed before merging — text diffs formatting changes too, which matters for prose in a way it wouldn't for JSON.
DevOps & SRE
Diff two versions of an nginx.conf, a Kubernetes manifest or a systemd unit file between environments or before/after an incident, and keep the unified output as a record of what was changed and when.
Examples
A one-word change
port: 8080 port: 9090
− port: 8080 + port: 9090
Only `8080` and `9090` are highlighted inside the line. The word diff is what makes a one-character change visible at a glance instead of two full lines of colour.
An insertion is an insertion
a c --- a b c
a + b c
A positional comparison would call line 2 modified and line 3 added. LCS finds the longest common run — `a` and `c` — and reports the single insertion between them.
A unified patch
two files differing on line 2
--- original +++ changed @@ -1,3 +1,3 @@ a -b +B c
`@@ -1,3 +1,3 @@` says the hunk covers three lines from line 1 on both sides. Save this and `git apply` will take it.
Ignoring whitespace
const x = 1 const x = 1
No changes with Ignore whitespace on
Useful when an editor or formatter has reindented a file and you want to know whether anything real changed underneath.
Common errors
| Message | Cause | Fix |
|---|---|---|
| Every line is marked as changed | Different line endings. A file with CRLF compared against one with LF differs on every line by an invisible character. | Line endings are normalised here, so this will not happen on this page. If your own diff tool shows it, that is the cause — check `core.autocrlf` or your editor's setting. |
| A moved block shows as a deletion and an addition | Standard diff algorithms do not detect moves. A block that travelled from the top of the file to the bottom was removed from one place and added at another. | Expected behaviour, and what git does too. `git diff --color-moved` is the exception, and it is a display heuristic rather than a different algorithm. |
| The word diff is missing on some lines | The two lines had nothing in common, so a word diff would produce noise rather than insight. | Nothing to fix — the plain line pair is the more readable output in that case. |
| Compared line by line (over 4000 lines) | The LCS table is quadratic in the number of lines, so beyond a cap the tool falls back to a positional comparison rather than freezing the page. | Diff the section you care about, or use `git diff` locally. The fallback is reported rather than applied silently. |
| Trailing whitespace differences are invisible | A space at the end of a line is a real character but renders as nothing. | The lines are still reported as different. If the highlight looks empty, that is the change. |
Frequently asked questions
›Is my text uploaded anywhere?
No. Both texts are compared in your browser, and nothing is transmitted, stored or logged. This matters more than it sounds for a diff tool — the things people compare are usually config files, contracts and logs, which is exactly the material you would not paste into a service that keeps it.
›How is this different from the JSON diff?
This compares text, so formatting is a change: reindenting a file or reordering the keys of a JSON object will show up here. The JSON diff parses both sides first and compares values, so neither of those registers. Use this for anything textual, and the JSON diff when both sides are JSON and you only care about the data.
›What algorithm is used?
A longest-common-subsequence diff over the lines, which is the same family of algorithm git uses. It finds the largest set of lines appearing in the same order in both texts and treats everything else as inserted or deleted, which is what makes an insertion read as one change rather than shifting everything after it.
›Can I apply the unified diff with git?
Yes. The output is the standard unified format with three lines of context, and `git apply` or `patch -p0` will take it. The file names in the header are placeholders — edit them if you are applying to a specific path.
›Why does 'ignore whitespace' still show a line as changed?
Because that option collapses runs of whitespace and trims the ends; it does not remove whitespace entirely. `a b` and `ab` are genuinely different text, and treating them as equal would hide real changes in code.
›Can it compare two files rather than pasted text?
Not yet — paste the contents in. Everything here runs client-side, so a file picker is possible; it is not built because paste covers the overwhelming majority of what this page is used for.
›Can I use this as a code diff checker?
Yes — it operates on plain text, so any programming language works exactly the same as prose does: it does not parse syntax, so it will not tell you that a moved function is semantically unchanged, but line and word-level highlighting is exactly what you want for a before/after snippet. There is no separate 'code mode' because none is needed — indentation-sensitive languages benefit from Ignore whitespace, and everything else needs nothing extra.
›Does it diff character by character?
No — it stops at word level, one level coarser than character-by-character. A word diff is deliberately the finer of the two granularities on offer: character-level diffs of prose or code tend to fragment a single renamed identifier or word into several tiny highlighted runs, which is harder to read than the same change shown as one word.
Last updated