Text Compare & Diff Checker

About Text Compare & Diff Checker

Text Compare & Diff Checker puts two versions of a text side by side and marks what changed. You choose the granularity — character, word, or line — and four normalizations decide what counts as a difference before the comparison runs. The result appears as two panes, with removals highlighted in A and additions highlighted in B.

A diff answers a question you have not stated out loud, and the granularity is where you state it. Line mode answers "which lines were edited" — what version control shows and what a review needs. Word mode answers "what changed in this sentence", treating runs of whitespace as insignificant, so reflowing a paragraph produces no diff at all. Character mode answers "exactly which characters differ", the only useful mode for a hash or a port number. The wrong choice gives a technically correct result that hides the change you were looking for.

How to use this developer tool

Paste the original into pane A and the revised version into pane B.
Pick the granularity: line for files and configuration, word for prose, character for short values.
Set the four normalizations before the first run, not after. Ignore case, ignore whitespace differences, ignore blank lines, and ignore line order all default to off.
Run the comparison and read both result panes. Pane A shows the original with removals highlighted; pane B shows the revision with additions highlighted.
If the whole file looks changed, turn on ignore whitespace and run again. The difference between the two runs tells you whether the change was real or cosmetic.

Worked example: a one-character change in a config file

Two versions of the same service configuration differ by a single port digit. In line mode the tool reports the whole line as replaced, which is the correct answer to "which line changed" and a frustrating one if you wanted to know which character changed.

A, then B

A:
server:
  host: api.internal
  port: 8080
  retries: 3
timeout: 30

B:
server:
  host: api.internal
  port: 8443
  retries: 3
timeout: 30

Line mode result

Pane "A differences"
server:
  host: api.internal
  port: 8080          <- highlighted as removed
  retries: 3
timeout: 30

Pane "B differences"
server:
  host: api.internal
  port: 8443          <- highlighted as added
  retries: 3
timeout: 30

Switch the same pair to character mode and the result narrows to the three digits that actually moved: 080 is marked removed and 443 marked added, with the leading 8 unchanged. That is the right mode once you already know which line to look at, and the wrong mode for finding it.

Granularity and the four normalizations

The first three rows are the mode switch; the last four are the checkboxes. Line endings are absent because CRLF and CR become LF on both sides first, so mixed endings never register as a difference.

Setting	What the comparison sees	Watch out for
Character mode	Individual characters, whitespace included	Unreadable past a few lines, and slower
Word mode	Whitespace-separated tokens; runs of whitespace are insignificant	Reflowing a paragraph produces no diff at all
Line mode	Whole lines, including the trailing newline	A one-character edit becomes a full line replacement
Ignore case	Both sides lowercased first	Hides a rename that only changed capitalization
Ignore whitespace differences	Space and tab runs collapsed; spaces around newlines removed	Hides real changes in Python and YAML, where indentation is syntax
Ignore blank lines	Empty and whitespace-only lines dropped	Hides a deliberate blank line in fixtures and Markdown
Ignore line order	Both sides sorted line by line first	Genuinely different files can compare as identical

Troubleshooting

Every line is reported as changed even though the content looks the same.

Why it happens Something rewrote the whitespace on every line: a formatter ran, indentation moved from tabs to spaces, or an editor stripped trailing spaces on save. Line endings are not the culprit here, because CRLF and CR are normalized to LF on both sides before the comparison.

Fix Turn on ignore whitespace differences and run again. If the diff collapses to nothing, the change was cosmetic. Commit the formatting separately from the logic so the next reviewer sees one or the other, never both at once.

A block that was moved is reported as a deletion and an identical insertion.

Why it happens The algorithm matches the longest common subsequence, and it has no concept of a move. Relocating four lines from the top of a file to the bottom is expressed as those four lines removed at the top and the same four added at the bottom.

Fix Turn on ignore line order to confirm that the two files contain the same lines, then turn it back off to review the positions deliberately. For a large reorganization, diff each moved block against its new location separately.

Ignore line order makes two files that are clearly different look identical.

Why it happens That option sorts every line on both sides before comparing, so it discards sequence entirely. Two files that contain the same set of lines in any arrangement will compare as identical.

Fix Use it only as a quick membership check, in the same spirit as the List Compare Tool. Never use it to approve a change in a file where order carries meaning, such as a route table, a middleware chain, or a migration sequence.

Word mode reports no difference after a paragraph was rewrapped.

Why it happens Word mode treats runs of whitespace as insignificant by design, so changing where the lines break, or turning two spaces into one, is not a difference.

Fix This is usually what you want for prose. Switch to line or character mode when the whitespace itself is the thing you are checking, for instance a fixture file or a fixed-width report.

When this tool is the right choice

Comparing a configuration file between two environments and seeing exactly which values differ.
Checking what an automated tool changed in a file, when the change never went through version control.
Reviewing an edited paragraph in word mode, where the result reads like tracked changes.
Confirming that two long values — a token, a checksum, a base64 blob — are identical, and finding where they diverge if they are not.

When to use something else

Comparing two lists where only membership matters and order does not. The List Compare Tool answers that directly and gives you the intersection as a copyable list.
Comparing two JSON documents whose keys are in different orders. Format both with the JSON Formatter first, or compare the parsed values, because a text diff reports every reordered key as a change.
Merging changes or reviewing a branch's history. A text diff has no notion of a common ancestor; use git for a three-way merge.

Privacy and data handling

Both texts are compared in this browser tab and are never uploaded, stored, or logged. Diffing is a habit people carry into sensitive material — a production config against a staging one, a log excerpt around an incident — so paste the smallest excerpt that still shows the change. Local processing keeps content off our servers; it does not make it appropriate to copy material out of the system that holds it.

Related developer tools

Frequently asked questions

Do I need to worry about Windows line endings?

No. Both sides have CRLF and CR converted to LF before anything is compared, so a file saved on Windows and one saved on Linux will not differ for that reason alone. This is one of the few places where line endings are handled for you.

Which mode should I start with?

Line mode, almost always. It maps to how files are actually edited and reviewed, and it narrows the search fast. Move to character mode once you know which line to examine, and use word mode when the text is prose rather than code.

Does the diff tell me which version is correct?

No. It reports differences, and nothing about them implies direction or correctness. Deciding which version should survive is a matter for tests, review, and the system the file came from.

Why does ignore whitespace leave the indentation on my first line?

The option collapses runs of spaces and tabs to a single space and removes spaces around newlines. Leading whitespace at the very start of the text is not adjacent to a newline, so one space can remain there. It has no effect on the comparison as long as both sides are treated the same way.

Can I compare more than two texts?

Not in one pass, and a three-way comparison is a genuinely different operation because it needs a common ancestor to attribute each change. Compare A against B, then B against C, or use git's merge tooling when you need to reconcile two edits to the same original.

How large a text can it handle?

The comparison runs in this tab, so it is bounded by browser memory and by the mode you chose. Line mode on files of a few thousand lines is comfortable; character mode on the same input will be noticeably slower and much harder to read.