Spotting what's different between two emails, contracts, or pasted blobs that "look the same". Comparing config files or environment variables across two environments (staging vs prod). Reviewing changes to a piece of copy that was edited in Word/Docs by someone else. Diffing two query results, log snippets, or JSON blobs (use the JSON Formatter first to canonicalize). Quick sanity check on a search-and-replace before committing it.

This is a line diff, not a word diff. One character changed in the middle of a long line marks the entire line as changed. For prose-level diffing of paragraphs, you may want a tool that tokenises into words. "Ignore whitespace" affects comparison only, not display. Lines that differ only in trailing spaces or indentation collapse into the unchanged column, but the original whitespace is still shown. "Ignore case" likewise. "TODO" and "todo" compare equal, but the original casing is rendered. Order matters. If you swap two lines, the diff shows both as removed-and-re-added, not as a "moved" pair. There's no move detection. Big inputs (10k+ lines) can be slow. The LCS algorithm is O(m·n) — fine for typical files, sluggish for very large ones. Diff small chunks at a time. Trailing newlines count as a line. Two inputs that differ only in whether they end with a newline will show one trailing addition or removal.

Comparateur de Texte

Comparez deux blocs de texte ligne par ligne. Ajouts, suppressions, contexte. Vue côte à côte ou unifiée.

Original

Changed

View

Ignore whitespace Ignore case

Résultat

What is this for?

Comparing two versions of a piece of text — a paragraph, a config file, a SQL query, a list — and seeing exactly which lines were added, removed, or left alone. Even when you don't have git diff handy or the text isn't in version control. The output is the same line-level diff you'd see in a code review: green for additions, red for removals, plain for unchanged context.

When to use it

Spotting what's different between two emails, contracts, or pasted blobs that "look the same".
Comparing config files or environment variables across two environments (staging vs prod).
Reviewing changes to a piece of copy that was edited in Word/Docs by someone else.
Diffing two query results, log snippets, or JSON blobs (use the JSON Formatter first to canonicalize).
Quick sanity check on a search-and-replace before committing it.

Side-by-side vs unified

Side-by-side — easier to scan small changes line-by-line; the original is on the left, the new version on the right.
Unified — closer to git diff output; better for sharing or printing, and easier to follow when changes are sparse.

Common gotchas

This is a line diff, not a word diff. One character changed in the middle of a long line marks the entire line as changed. For prose-level diffing of paragraphs, you may want a tool that tokenises into words.
"Ignore whitespace" affects comparison only, not display. Lines that differ only in trailing spaces or indentation collapse into the unchanged column, but the original whitespace is still shown.
"Ignore case" likewise. "TODO" and "todo" compare equal, but the original casing is rendered.
Order matters. If you swap two lines, the diff shows both as removed-and-re-added, not as a "moved" pair. There's no move detection.
Big inputs (10k+ lines) can be slow. The LCS algorithm is O(m·n) — fine for typical files, sluggish for very large ones. Diff small chunks at a time.
Trailing newlines count as a line. Two inputs that differ only in whether they end with a newline will show one trailing addition or removal.