Text Compare
100% private — runs on your device, never uploaded. Works offline once loaded.
Paste two versions of any text to see a line-by-line diff with additions highlighted in green and deletions in red. Everything runs locally in your browser.
How the comparison actually works
The tool splits both texts into lines and runs a line-by-line diff — the same class of algorithm, based on finding the Longest Common Subsequence, that powers git diff and most code-review tools. Lines present in both texts stay neutral, a line that only appears on the right is shown as a green addition, a line that only exists on the left is a red deletion, and an edited line typically appears as a deletion immediately followed by its replacement.
When line-based diffing is the right tool
This approach works best for anything organized into discrete lines rather than free-flowing prose.
- Comparing two revisions of a contract or policy document clause by clause
- Reviewing what changed between two versions of a config file — nginx.conf, a .env file, a YAML manifest
- Checking a translated or localized string file against its source after a content update
- Verifying a copy-paste didn't silently alter formatting or drop a line
What a line diff won't tell you
A pure line diff treats a paragraph that simply moved to a different position as one deletion plus one addition — it has no concept of "this block relocated," only where lines line up positionally between the two versions. It's also sensitive to line-level noise: a sentence that's identical except for a single word will still show the entire line as changed, because the comparison works at line granularity, not word-by-word.
Tip: watch for invisible whitespace
If two lines look identical to your eye but still show as different, check for trailing spaces, tabs, or mismatched line endings — Windows-style \r\n versus Unix-style \n. These are invisible when reading normally but count as a real difference to a text-level comparison, and they're a common source of "why does this line show as changed" confusion when comparing files exported from different tools.
A practical way to read the output
Start by scanning for the largest changed blocks rather than trying to read every red and green line in order. Big blocks usually indicate inserted sections, removed clauses, or pasted configuration changes; once you understand those, smaller edits are easier to interpret. For prose, it often helps to compare one paragraph at a time. For config files, focus on added keys, removed keys, and changed values. A line diff is especially useful as a sanity check before publishing or deploying because it shows exactly what changed, even when the visible formatting looks almost identical.
Frequently asked questions
Is my text uploaded?
No — comparison happens entirely on your device.
Does it work line by line?
Yes — differences are shown per line.
Is my text uploaded to a server to compare it?
No — both texts are compared entirely in your browser; nothing is transmitted anywhere.
Does it compare line by line or word by word?
Line by line — a changed line is shown as a full deletion and a full addition, even if only one word inside it actually changed.
Can it detect a paragraph that just moved position?
No — a moved block is shown as a deletion at its old position and an addition at its new one, since the algorithm matches lines positionally, not by content relocation.
Will trailing spaces or different line endings show up as changes?
Yes — a line with a trailing space or a \r\n versus \n ending will be flagged as different even if the visible text looks identical.
Is there a limit on how much text I can paste?
There's no server-side limit since comparison happens locally; extremely long texts (tens of thousands of lines) may simply take a moment longer to render.
Does the diff care about capitalization or punctuation?
Yes — the comparison is exact by default, so a change in capitalization, punctuation, or spacing within a line will register as a difference on that line.
Is this useful for contracts and policy drafts, or only for code?
It is useful for both. Lawyers, editors, operations teams, and developers all use line diffs to verify what changed between two text versions before approving or sending them onward.
Why does one edited sentence show as a full removed line and a full added line?
Because this tool compares at line granularity. Even a one-word edit marks the whole line as changed, which is normal for a line-based diff and often clearer than trying to infer micro-edits automatically.
Advertisement