compare texts. spot changes.

compare two texts side by side with line-by-line diff highlighting. see additions, removals, and unchanged lines instantly.

original
modified

What this tool does

Paste two pieces of text — old version on the left, new version on the right — and see exactly what changed, line-by-line, with additions and deletions highlighted. Useful for comparing config files, contract revisions, code snippets, log outputs, or any two similar-but-not-identical chunks of text.

What “diff” actually computes

A diff is the answer to a deceptively simple question: given two sequences, what is the shortest list of insertions and deletions that transforms the first into the second? That list is what gets displayed as the highlighted changes.

The interesting subtlety is that “the shortest list” is not unique. Consider:

  • Old: A B C
  • New: B C A

You could express this as “delete A from the start, insert A at the end” or “delete B C from the start, insert B C in the middle.” Both have the same edit distance. Different diff algorithms make different choices, and that is why two diff tools can show the same change in different shapes.

The Myers algorithm

Most modern diff tools — including this one, Git, and most code editors — use Myers' algorithm or a variant. It was published in 1986 and remains the standard because it is fast (O(ND) where N is the input size and D is the edit distance) and produces “intuitive” results that align well with how humans read changes.

The intuition is to find the longest common subsequence of the two inputs — the longest stretch of items that appear in the same relative order in both. Whatever is not part of that subsequence has to be either an insertion or a deletion. The diff is the complement of the longest match.

For most pairs of inputs, the Myers result is what you want. For some adversarial pairs (highly repetitive content, transposed blocks), it can produce technically-minimal-but- unreadable output. Tools like git diff offer alternative algorithms (patience, histogram) that are sometimes more readable on real-world inputs at the cost of being slower or non-minimal.

Line diff vs character diff vs word diff

The unit of comparison matters a lot for what the output looks like.

Line diffcompares line-by-line. The smallest change shown is “this line was modified.” Good for code and config files where lines are meaningful units. Bad for prose, where reflowing a paragraph causes a whole-paragraph diff that obscures what actually changed.

Word diff compares word-by-word within lines. Better for prose. Catches the actual changed words and leaves the rest of the line alone. Worse for code, where whitespace and punctuation matter.

Character diff compares character-by-character. Catches the smallest possible changes — useful for debugging encoding issues, trailing whitespace, or suspicious-looking similar-but-not-identical characters (smart quotes vs straight quotes, em-dash vs en-dash). Often too noisy for general use.

This tool defaults to line diff, which is the right pick for most situations.

Common things to compare

  • Two versions of a config file — what actually changed in production?
  • Contract drafts — what is different between the version your client sent and the version your lawyer returned?
  • Log outputs — same job ran twice, why did it produce different results?
  • Generated code — your build tool regenerated a file. What changed?
  • Two emails / responses — figuring out how the wording shifted across drafts.
  • JSON or YAML payloads — same API call succeeded once and failed another. Where is the difference?

If a JSON diff looks chaotic

Format both sides with the same indentation first (paste them through the JSON formatter) before diffing. JSON keys can serialize in different orders from the same source, and a line-based diff will show the entire document as changed even when nothing semantic differs. A proper JSON-aware diff tool can ignore key order.

Why this is a browser-only tool

Diffing is a pure local computation. Your input might be configuration with credentials, code with proprietary logic, or contract language under NDA — none of which has any business being uploaded to a third party. The diff runs in your browser using the same algorithms a desktop diff tool would use, with no network involvement.

What this tool does

Paste two pieces of text — old version on the left, new version on the right — and see exactly what changed, line-by-line, with additions and deletions highlighted. Useful for comparing config files, contract revisions, code snippets, log outputs, or any two similar-but-not-identical chunks of text.

What “diff” actually computes

A diff is the answer to a deceptively simple question: given two sequences, what is the shortest list of insertions and deletions that transforms the first into the second? That list is what gets displayed as the highlighted changes.

The interesting subtlety is that “the shortest list” is not unique. Consider:

  • Old: A B C
  • New: B C A

You could express this as “delete A from the start, insert A at the end” or “delete B C from the start, insert B C in the middle.” Both have the same edit distance. Different diff algorithms make different choices, and that is why two diff tools can show the same change in different shapes.

The Myers algorithm

Most modern diff tools — including this one, Git, and most code editors — use Myers' algorithm or a variant. It was published in 1986 and remains the standard because it is fast (O(ND) where N is the input size and D is the edit distance) and produces “intuitive” results that align well with how humans read changes.

The intuition is to find the longest common subsequence of the two inputs — the longest stretch of items that appear in the same relative order in both. Whatever is not part of that subsequence has to be either an insertion or a deletion. The diff is the complement of the longest match.

For most pairs of inputs, the Myers result is what you want. For some adversarial pairs (highly repetitive content, transposed blocks), it can produce technically-minimal-but- unreadable output. Tools like git diff offer alternative algorithms (patience, histogram) that are sometimes more readable on real-world inputs at the cost of being slower or non-minimal.

Line diff vs character diff vs word diff

The unit of comparison matters a lot for what the output looks like.

Line diffcompares line-by-line. The smallest change shown is “this line was modified.” Good for code and config files where lines are meaningful units. Bad for prose, where reflowing a paragraph causes a whole-paragraph diff that obscures what actually changed.

Word diff compares word-by-word within lines. Better for prose. Catches the actual changed words and leaves the rest of the line alone. Worse for code, where whitespace and punctuation matter.

Character diff compares character-by-character. Catches the smallest possible changes — useful for debugging encoding issues, trailing whitespace, or suspicious-looking similar-but-not-identical characters (smart quotes vs straight quotes, em-dash vs en-dash). Often too noisy for general use.

This tool defaults to line diff, which is the right pick for most situations.

Common things to compare

  • Two versions of a config file — what actually changed in production?
  • Contract drafts — what is different between the version your client sent and the version your lawyer returned?
  • Log outputs — same job ran twice, why did it produce different results?
  • Generated code — your build tool regenerated a file. What changed?
  • Two emails / responses — figuring out how the wording shifted across drafts.
  • JSON or YAML payloads — same API call succeeded once and failed another. Where is the difference?

If a JSON diff looks chaotic

Format both sides with the same indentation first (paste them through the JSON formatter) before diffing. JSON keys can serialize in different orders from the same source, and a line-based diff will show the entire document as changed even when nothing semantic differs. A proper JSON-aware diff tool can ignore key order.

Why this is a browser-only tool

Diffing is a pure local computation. Your input might be configuration with credentials, code with proprietary logic, or contract language under NDA — none of which has any business being uploaded to a third party. The diff runs in your browser using the same algorithms a desktop diff tool would use, with no network involvement.

more free tools

PDF utilities, image tools, developer helpers — all free, no signup.

Something wrong?