Does this compare word-by-word or line-by-line?

Line-by-line. Each line of the Original and Modified text is treated as a single unit for comparison, which matches how most code review tools and version control diffs work, and makes changes in structured text (code, config files, lists) easy to scan.

Why does a single changed word show the whole line as removed and re-added?

Since comparison happens at the line level, changing even one character within a line makes that line no longer match its old version exactly, so it's shown as one removed line and one added line rather than a partial in-line edit.

Is there a limit to how much text I can compare?

Very large inputs are capped to keep the comparison fast in your browser, since the underlying algorithm's work grows with the size of both texts multiplied together. For most documents, config files, and code snippets — even several thousand lines — it runs instantly.

Is my text uploaded anywhere?

No. The comparison runs entirely in your browser using JavaScript — nothing you paste into either box is sent to a server, so it's safe to compare private drafts, code, or configuration files.

Diff Checker — Compare Two Texts

Compare two blocks of text line by line, with added and removed lines clearly highlighted.

Original

Modified

Diff

Enter text in both boxes to see the difference.

How to use the Diff Checker

Paste the earlier version of the text into Original.
Paste the newer version into Modified.
Read the highlighted diff: added lines are marked with +, removed lines with −, and the summary shows how many of each.

About the Diff Checker

A diff checker compares two versions of text — an 'Original' and a 'Modified' version — and highlights exactly what changed between them, line by line, instead of making you scan both versions manually looking for differences. It's the same core idea behind the diff view in Git and other version control tools, applied to any plain text you paste in.

This tool compares your two text blocks using a line-based longest-common-subsequence algorithm, the same general approach used by most diff tools, so unrelated lines aren't flagged as changed just because a line above them shifted. Matching lines are shown unchanged, removed lines are struck through with a red background, and added lines get a green background, with a running count of how many lines were added and removed. Everything runs locally in your browser — nothing you paste is uploaded anywhere.

Worked example

Example: comparing a 10-line config file against a version where only line 6 changed shows lines 1–5 and 7–10 as unchanged, line 6's old value struck through in red, and its new value added in green directly below — instead of highlighting the whole file as different.

How lines are matched

The checker finds the longest common subsequence of lines: the largest set of lines that appear in both texts in the same order. Those lines are shown as unchanged, and everything else is a removal from the original or an addition in the modified version. That's why inserting a line near the top doesn't mark every line below it as changed. Lines must match exactly, so a trailing space or a change in indentation is enough to make a line show as different.

Very large inputs are capped to keep your browser responsive: comparing two texts of about 2,000 lines each is fine, while much larger pairs fall back to showing the raw text.

Getting cleaner results

Normalize first. If one version was re-indented or had trailing spaces trimmed, every affected line will show as changed. Clean both versions the same way before comparing.
Format JSON before diffing. Two minified JSON files are each one long line, so any change marks the whole thing as different. Run both through the JSON formatter first to get a line per key.
Sort lists when order doesn't matter. For lists of names, packages, or IDs, sorting both versions first shows only the real additions and removals.
Break up long paragraphs. Prose with one paragraph per line produces big blocks of changes; putting each sentence on its own line makes edits much easier to spot.

Reading the summary

The added and removed counts are a quick sanity check. A small edit should show a handful of lines; if a one-word change reports hundreds of removed and added lines, the cause is almost always whitespace or line structure, not content. Equal numbers of added and removed lines in the same spot usually mean lines were edited rather than truly added or deleted.

Frequently asked questions

Does this compare word-by-word or line-by-line?: Line-by-line. Each line of the Original and Modified text is treated as a single unit for comparison, which matches how most code review tools and version control diffs work, and makes changes in structured text (code, config files, lists) easy to scan.
Why does a single changed word show the whole line as removed and re-added?: Since comparison happens at the line level, changing even one character within a line makes that line no longer match its old version exactly, so it's shown as one removed line and one added line rather than a partial in-line edit.
Is there a limit to how much text I can compare?: Very large inputs are capped to keep the comparison fast in your browser, since the underlying algorithm's work grows with the size of both texts multiplied together. For most documents, config files, and code snippets — even several thousand lines — it runs instantly.
Is my text uploaded anywhere?: No. The comparison runs entirely in your browser using JavaScript — nothing you paste into either box is sent to a server, so it's safe to compare private drafts, code, or configuration files.