How does the diff work?

The tool compares text line by line using a longest common subsequence algorithm. Lines present only in the original are shown in red, lines only in the modified version are shown in green, and unchanged lines are shown in grey.

Does it support character-level diff?

The current view shows line-level differences. Lines that differ are marked as removed and added, making it easy to spot changes across any block of text.

Is there a size limit on the text I can compare?

No hard limit is enforced, but very large texts (thousands of lines) may take a moment to process as the diff runs entirely in your browser.

Can I use the diff checker to compare code or config files?

Yes. Paste any two blocks of text — source code, JSON configs, YAML files, SQL queries, or plain prose. The line-by-line diff works the same regardless of content type.

What do the colours in the diff output mean?

Green lines are present in the second block but not the first (added). Red lines are present in the first block but not the second (removed). Unchanged lines appear without a colour highlight.

Private by defaultRuns in your browser

Diff checker

Paste original and modified text to see exactly what changed — added, removed, and unchanged lines.

Original1 lines

Modified1 lines

Quick samplesUseful for testing

Diff Checker

About this tool

Comparing two versions of a file by eye is reliable for about ten lines and hopeless after that. A diff does it mechanically, finding the longest common subsequence between the two texts and reporting everything outside it as an insertion or a deletion. That framing explains a diff's occasional strangeness: it has no concept of a line being edited, only of one line disappearing and another appearing, and it has no idea that a block of code was moved rather than deleted in one place and added in another. It is the format underneath git diff, code review, and every merge conflict you have ever resolved. Reading one well is a skill worth having outside version control too — comparing two config files across environments, checking an API response against a fixture, seeing what a formatter changed, or working out why a deployment behaves differently from staging. This tool compares two blocks of text line by line and highlights additions in green, deletions in red, and unchanged context in grey. Both texts stay in your browser; nothing is uploaded.

No signup requiredRuns in your browserInstant results

How to use

1
Paste your original text in the left panel and the modified text in the right panel.
2
Differences are highlighted instantly — green for additions, red for deletions.
3
Use it to compare code snippets, config files, or any two blocks of text.
4
Scroll through the diff to review every changed line.

Why use this tool?

→
Compare two versions of a config file, script, or document to find what changed.
→
Review code changes when you don't have access to a version control diff view.
→
Verify that a copied or generated text matches the original with no unexpected edits.

ExamplesInput → output

Spot a changed word

Input

Left: The quick brown fox
Right: The slow brown fox

Outputquick → slow highlighted as changed

Added line

Input

Left: line1
line2
Right: line1
line2
line3

Outputline3 highlighted as added

Common errorsAnd how to fix them

Every line shows as changed when the files look identical

Cause: Line endings differ. A file saved on Windows ends lines with CRLF and one saved on macOS or Linux with LF, so every line differs by an invisible carriage return.

Fix: Normalise line endings before comparing — most editors can convert a file, and git's core.autocrlf setting controls this at commit time. A trailing newline on one side but not the other produces the same effect on the final line only.

A reformatted file shows as entirely rewritten

Cause: A line-based diff compares whole lines. Reindenting, rewrapping, or changing quote style touches every line, so nothing survives as common context even though the meaning is unchanged.

Fix: Diff the formatting change separately from the logic change — this is why formatting-only commits are kept apart in review. Comparing the two files after running both through the same formatter isolates the real difference.

Moved code appears as a large deletion and a large addition

Cause: The longest common subsequence algorithm cannot represent a move. A block relocated from the top of a file to the bottom is, to the algorithm, one block gone and an unrelated block arrived.

Fix: This is a limitation of the format rather than something to fix. When reviewing, check that the deleted and added blocks are genuinely identical before assuming a move was clean.

Frequently asked questionsCommon questions answered

These answers explain common diff checker tasks, expected input formats, and edge cases so both visitors and search engines can understand what this tool does.

How does the diff work?: The tool compares text line by line using a longest common subsequence algorithm. Lines present only in the original are shown in red, lines only in the modified version are shown in green, and unchanged lines are shown in grey.
Does it support character-level diff?: The current view shows line-level differences. Lines that differ are marked as removed and added, making it easy to spot changes across any block of text.
Is there a size limit on the text I can compare?: No hard limit is enforced, but very large texts (thousands of lines) may take a moment to process as the diff runs entirely in your browser.
Can I use the diff checker to compare code or config files?: Yes. Paste any two blocks of text — source code, JSON configs, YAML files, SQL queries, or plain prose. The line-by-line diff works the same regardless of content type.
What do the colours in the diff output mean?: Green lines are present in the second block but not the first (added). Red lines are present in the first block but not the second (removed). Unchanged lines appear without a colour highlight.