Text Diff Checker
Paste two versions of a text and see what changed between them. Additions, deletions and modifications are highlighted line by line, with an optional word-level view for spotting small edits inside long paragraphs.
- Free, no sign-up
- Runs in your browser
- Nothing uploaded
- Updated Sep 2026
At a glance
- Compares
- Any two texts — prose, code, configuration, logs
- Granularity
- Line level, or word level within changed lines
- Algorithm
- Longest common subsequence, the basis of most diff tools
- Options
- Ignore whitespace, ignore case, unified or side-by-side
- Processing
- Entirely client-side — nothing uploaded
- Cost
- Free, no account, no size limit beyond browser memory
Line diff or word diff?
Both views answer different questions, and choosing the wrong one makes changes harder to see rather than easier.
Line-level treats each line as a unit: it either matches or it does not.
This is what git diff does by default and what suits code, where lines are
short and a changed line is genuinely a changed unit. Its weakness shows on prose — edit one
word in a 400-word paragraph stored as a single line, and the whole paragraph is marked
changed, telling you nothing.
Word-level goes inside changed lines and marks individual words. That turns a wall of red and green into a precise view: this word was replaced, that clause was added. It is much the better choice for documents, contracts, translations and anything where the text flows.
The usual workflow is to start at line level to see the shape of the change, then switch to word level on anything that looks suspicious. For prose specifically, word level is almost always the right default.
When "identical" texts are not
A common frustration: two files that look the same produce a diff full of changes. The cause is nearly always invisible characters.
- Line endings. Windows uses CRLF, Unix and macOS use LF. A file that has been through both shows every line as changed. This tool normalises line endings before comparing, which is why it often reports no difference where others report hundreds.
- Trailing whitespace. Invisible spaces at the end of lines, usually left by an editor. Turn on "ignore whitespace" to skip them.
- Tabs versus spaces. Visually identical at the same indent level, entirely different bytes.
- Smart quotes and dashes. Text pasted through a word processor arrives with curly quotes and en dashes that look almost like their ASCII equivalents.
- Non-breaking spaces. Copied from a web page, these look like ordinary spaces and are not.
- Byte order marks. An invisible marker at the start of a file that makes the first line differ even when it visibly does not.
If a diff shows changes you cannot see, one of these is almost certainly why.
What this is good for
The obvious use is code review, but a browser diff earns its place mostly for things outside a repository:
Comparing document drafts. Track Changes only works if everyone used it in the same document. When a draft comes back as a fresh file, a word-level diff is the fastest way to find what moved.
Checking contracts and terms. Paste the old and new versions and see precisely which clauses changed — far more reliable than reading both and trusting your attention.
Config drift. Comparing a working configuration against a broken one usually finds the problem in seconds.
Verifying a conversion round trip. Convert a file to another format and back, then diff against the original. If the diff is empty, the conversion was lossless — a quick way to test the JSON to YAML and YAML to JSON pair, for instance.
Because everything runs locally, none of these involve sending a contract or a production config to someone else's server — which is the main reason to use a client-side tool for this particular job.
How to use the Diff Checker
-
Paste the original into the left pane
The version you are comparing from. Deletions are measured against this.
-
Paste the new version on the right
The version you are comparing to. Additions are measured against this.
-
Choose your granularity
Line level for code, word level for prose. Switch between them freely — the comparison is instant.
-
Turn on ignore options if needed
Ignore whitespace removes noise from indentation and trailing spaces. Ignore case is useful when comparing text that has been through a system that changed capitalisation.
Frequently asked questions
Is my text uploaded anywhere?
No. The comparison runs in JavaScript in your browser. That matters here more than for most tools, because people diff contracts, credentials and production configuration.
Why does it show changes when the texts look identical?
Almost always invisible characters — trailing spaces, tabs against spaces, curly quotes from a word processor, non-breaking spaces copied from a web page, or a byte order mark. Turning on "ignore whitespace" resolves most of them.
What is the difference between line and word diff?
Line diff marks whole lines as changed, which suits code. Word diff goes inside changed lines to mark individual words, which suits prose. Editing one word in a long paragraph shows as an entire changed line in the first view and a single changed word in the second.
Can it compare files rather than pasted text?
Yes — upload a file into either pane. The file is read locally with the browser's FileReader and never transmitted.
How large can the texts be?
A few thousand lines each compares comfortably. Diff algorithms scale with the product of both lengths, so very large files slow noticeably. For anything of that size, a command-line diff is the better tool.
Does it handle different line endings?
Yes. CRLF and LF are normalised before comparison, so a file that has moved between Windows and Unix does not show every line as changed — which is the single most common false positive in diff tools that do not normalise.