Text Diff Checker

Comparing text the way Git does

A diff checker answers one question fast: what changed between two versions of some text? Whether you are reviewing a pull request snippet, comparing two API responses, or proofreading an edited paragraph, seeing the additions and removals highlighted is far quicker than reading both versions top to bottom.

Line diff vs word diff vs char diff

The granularity you choose changes what counts as a change. A line diff compares whole lines and is ideal for code, configs, and logs, where a line is a meaningful unit. A word diffcompares token by token and shines on prose, where reflowing a paragraph would otherwise mark every line as changed. A char diff goes finest, pinpointing a single altered character — perfect for spotting a typo or a flipped digit.

How the algorithm decides

Under the hood, text diffing finds the longest common subsequence: the longest ordered run of lines or words that appears in both inputs. Everything outside that shared run is classified as added or removed. This is the same foundation used by the Unix diff utility and by Git when it renders a commit.

- const timeout = 3000;
+ const timeout = 5000;
  retry(request, timeout);

Here a single line changed: the old value is shown with a minus, the new value with a plus, and the surrounding context line stays neutral.

A worked example: the same edit in three modes

Suppose you tweak one sentence in a README. The original is The cache expires after 30 seconds by default. and the edit is The cache expires after 60 seconds unless overridden. What you see depends entirely on the mode you pick:

Lines:  - The cache expires after 30 seconds by default.
        + The cache expires after 60 seconds unless overridden.

Words:  The cache expires after [30→60] seconds [by default→unless overridden].

Chars:  ...after 3[0→]0... (only the changed digit and tail differ)

In line mode the whole sentence is flagged as one removal plus one addition, even though only two phrases moved — accurate, but you have to re-read the line to find the real change. In word mode the diff isolates exactly the two edits (30 became 60, by default became unless overridden) and leaves the rest untouched, which is why word mode is the right call for prose. Char mode is overkill here; it shines when the change is a single transposed letter or a flipped digit buried in an otherwise identical string, where word mode would still highlight the entire token.

Using diffs in code review

In review, a focused diff removes noise. Instead of re-reading an entire file, you paste only the function before and after a change and immediately see whether the refactor altered behaviour. It is equally useful for verifying that two environment configs match, confirming a generated file did not drift, or checking that a copy edit only touched the intended sentence.

Whitespace and significance

By default every character matters, including trailing spaces and indentation, because in Python, YAML, and Makefiles whitespace is part of the meaning. If indentation churn is hiding the real change, normalize both sides first so the diff highlights only what you care about.

Limitations to know

Diffs preserve order, so a block of code moved elsewhere shows up as one removal and one addition rather than a relocation. That is expected behaviour for line, word, and char modes alike — the paired red and green usually make the move obvious enough during review.

Related dev tools

• JSON Formatter — normalize two JSON payloads before diffing them.
• Markdown Editor — preview the docs you are comparing.
• Find & Replace — bulk-edit one side before a comparison.
• Hash Generator — confirm two files are byte-identical with a checksum.