🔄 Diff Checker

Compare two blocks of text and see exactly what changed — line-by-line with word-level highlights for modified lines.

Original Text
Modified Text

Press Ctrl+Enter to compare

⚠️
Context: lines

The two texts are identical.

No additions, deletions, or modifications found.

How to Read the Diff

+

Added Lines

Lines present only in the Modified text. Shown with green background and + prefix.

Removed Lines

Lines present only in the Original text. Shown with red background and − prefix.

Inline Word Diff

When a line is modified, individual changed words are highlighted more intensely within the line.

Longest common subsequence and word-level refinement

The comparison runs on the longest common subsequence algorithm. Both texts are split into lines, and the algorithm searches for the longest ordered sequence of lines that appears in both, without requiring those lines to be adjacent. Whatever belongs to that common sequence is unchanged; lines present only in the original are marked as removed; lines present only in the modified text are marked as added.

Where a removal and an addition sit next to each other and the lines resemble one another, the tool reports a modification rather than an unrelated pair. It then runs a second, finer comparison inside that line, splitting it into words and applying the same logic to highlight only the words that actually differ. That is what lets you see a single changed figure inside an otherwise identical sentence.

The only-changes mode uses the same result. Instead of printing every unchanged line it keeps the number of context lines you set, from 0 to 20, either side of each change and collapses the long identical stretches in between.

Comparing two versions of a short configuration

Take an original of five lines: host=localhost, port=8080, timeout=30, debug=false, retries=3. The modified version reads: host=localhost, port=9090, timeout=30, debug=true, retries=3, logging=verbose.

The longest common subsequence finds three lines shared in order: host=localhost, timeout=30 and retries=3. The port line differs, so it appears as a modification, and the inline word comparison highlights only 8080 against 9090 rather than dimming the whole line. The debug line is likewise a modification, with false against true. The final line, logging=verbose, exists only in the modified text and is reported as an addition.

The counts therefore read 1 added line, 0 removed lines, 2 modified lines and 3 unchanged lines, across 5 original and 6 modified lines. With only-changes switched on and context set to 1, the output would show the host line, both modified lines, the retries line and the new logging line, which for a file this short is almost everything.

Reading the colours and knowing what a diff misses

Read the result as instructions for turning the original into the modified text: removed lines are what you delete, added lines are what you insert, and modified lines are where the inline highlights show the precise substitution. The unified view is compact and easier to scan for a few scattered edits; the split view keeps corresponding passages side by side and suits reviewing rewritten prose.

The comparison is literal. Trailing spaces, tab versus space indentation and invisible line-ending differences all register as changes, which is why a file that looks identical can show every line as modified after passing through a different editor. Check the line endings first when that happens.

The bigger limitation is that a line-based diff has no concept of moved text. Cut a paragraph from the top of a document and paste it at the bottom, and the result reports a large deletion followed by a large insertion rather than a move. Reformatting that rewraps every line produces the same effect, so compare before reformatting where you can.

Frequently Asked Questions

Almost always line endings or invisible whitespace. Windows files end lines with a carriage return and line feed, Unix files with a line feed alone, and a text editor may add trailing spaces. The comparison is literal, so those differences register. Normalise the line endings and compare again.
Unified view lists the changes in a single column, which is compact and good for spotting a handful of edits in a long file. Split view puts the original and modified text in two aligned columns, which makes it easier to read rewritten paragraphs and to see corresponding passages next to one another.
Only-changes hides long stretches of identical text so you see just the edits. The context lines value, between 0 and 20, controls how many unchanged lines are kept either side of each change for orientation. Three is a common choice; increase it when you need more surrounding text to judge an edit.
No. A line-based comparison reports a moved block as a deletion in one place and an addition in another, because the algorithm preserves order when matching lines. That is expected behaviour rather than an error. Read the two regions together to recognise that the content itself is unchanged.
Yes. Line-based comparison with inline word highlighting suits source code, configuration files, CSV exports and log extracts as readily as prose. It has no language awareness, so it will not tell you that a change is syntactically significant, only precisely which characters on which lines differ.