Diff Checker — Compare Two Texts

What a diff checker tells you

A diff answers a narrow but extremely useful question: given an old version and a new version of the same text, what is the smallest set of edits that turns one into the other? The answer is expressed as lines removed from the original, lines added in the new version, and lines common to both. That framing is what makes a diff readable — instead of two walls of text you get a short list of the places that actually differ.

The typical moment you need one is when two things that should be identical are not. A config file works on staging and fails in production. A response body from an API changed between deployments and something downstream broke. A vendor sent an updated schema and only mentioned "a few small changes". Reading both versions side by side and trying to spot the differences by eye is slow and unreliable; a diff finds them in one pass, including the ones nobody would notice, like a renamed field buried in the middle of an unchanged block.

How the algorithm works

This tool computes the longest common subsequence (LCS) of the two line lists. A subsequence keeps relative order but need not be contiguous, so the LCS is the largest set of lines that appear in the same order in both texts. Those lines are the unchanged skeleton of the document. Anything in the original that is not part of it must have been removed; anything in the new version that is not part of it must have been added. The algorithm builds a table of common-prefix lengths and walks back through it to recover the alignment — the same approach that underpins diff, git diff and every code review tool you have used.

Two consequences are worth internalising. First, an edited line appears as a removal immediately followed by an addition: a line-level diff has no concept of changing a line in place, only of deleting one and inserting another. Second, when a large block moves, a plain LCS reports it as deleted from its old position and added at the new one rather than recognising the move, because a subsequence must preserve order. Both behaviours are correct; they are just easy to misread as "more changed than I expected".

Reading the output

Every line is prefixed the way a unified diff would prefix it, so the output can be read by anyone comfortable with version control:

The summary bar reports the totals: how many lines were added, how many removed, how many are common, and whether the two inputs are identical under the comparison settings you chose. When the counts are equal and interleaved, you are usually looking at modified lines rather than genuine insertions and deletions. Switching to Changes only hides the untouched lines, which is what you want when comparing two large documents that differ in three places.

The two comparison options

Ignore whitespace collapses runs of spaces and tabs to one space and trims both ends before comparing. Use it when a formatter has reindented a file, when tabs became spaces, or when trailing whitespace crept in — none of which change meaning in most formats. Ignore case lowercases both sides before comparing, which is the right setting for HTTP header names, hostnames, SQL keywords and hex digests, all of which are case-insensitive by definition. In both modes the lines are displayed exactly as you pasted them; only the matching is relaxed, so you can still see the real text.

Getting a meaningful diff out of structured data

Normalise before you compare

A line diff compares lines, which means the way a document is laid out matters as much as what it contains. Two JSON responses can carry identical data and share not one line — because one is minified onto a single line, or because the server emitted object keys in a different order. Before diffing structured data, run both sides through the JSON formatter with the same indentation and the sort-keys option, and both documents become directly comparable. The same applies to markup: pretty-print both with the XML formatter first, or you will be diffing formatting rather than content. For YAML, converting both to JSON with the YAML to JSON converter removes the many ways YAML lets you write the same value.

Line endings and invisible characters

If a diff claims every line changed, the cause is nearly always invisible. CRLF versus LF is the classic one, which this tool normalises for you. The next candidates are a byte-order mark on one file, a non-breaking space that looks exactly like a space, or a curly quote that replaced a straight one after a trip through a word processor. When a comparison insists two lines differ and they look identical, the hash generator settles it: hash each line and compare the digests, which reason about bytes rather than glyphs.

Diffing API responses

A productive workflow when an integration breaks is to capture a known-good response and the current one, then diff them. Send both requests with the API tester, copy each formatted body into one side here, and the change is usually obvious in seconds — a field renamed, a number that became a string, an array that became an object, a null where a value used to be. Do the same with response headers when caching or CORS behaviour changes unexpectedly; the HTTP headers guide explains which of them alter client behaviour. If one capture is a 200 and the other is a 500, diff the bodies anyway — error payloads often name the field that caused the failure.

Frequently asked questions

Related tools and reference