What diff algorithm do most tools use?

Many browser-based diff UIs build on Myers’ diff or similar longest-common-subsequence approaches that minimize edit operations. The goal is readable hunks—insertions and deletions—not necessarily the mathematically shortest patch for every edge case. Library-backed tools may also offer word-level or line-level granularity on top of the same core algorithm.

Unified diff vs side-by-side—which should I use?

Side-by-side is fastest for scanning large blocks where structure is similar; your eyes align paragraphs or functions across columns. Unified diff (one column with +/- lines) is compact, paste-friendly, and matches what version control emits—better for patches, code review comments, and sharing in tickets. Switch views based on whether you are reading or shipping a change.

How should I handle whitespace when comparing?

Turn off ignore-whitespace when whitespace is meaningful—Python, YAML, and some markup break on indentation. Turn it on when comparing prose or minified vs pretty-printed JSON so you see semantic changes. If your diff tool lacks toggles, normalize copies first (e.g. run text through a [JSON formatter](/json-formatter) for structured data) so noise does not hide real edits.

Is comparing code the same as comparing prose?

Same engine, different settings. Code benefits from line-oriented diffs, optional syntax awareness in some editors, and strict whitespace. Prose benefits from word-wrap discipline and sometimes sentence-level diff. For Markdown-heavy content, pair a text diff with [Markdown preview](/markdown-preview) to verify rendered output, since source diffs do not show heading or list reflow.

Why do small edits produce huge diffs sometimes?

Reordering, reflowing hard wraps, or re-encoding line endings (CRLF vs LF) can make every line look changed even when meaning is stable. Long lines moved as a block also explode visually. Normalize line endings, compare at word granularity if available, or use a dedicated structural diff for JSON/XML after formatting.

Text Diff Checker

v1.0.0

Compare two texts side by side and see additions, deletions, and changes highlighted line by line. Useful for comparing configs, code, or API responses.

Original

Modified

Diff Output

Paste text in both panels to see differences

Paste two versions of any text and see exactly what changed—line by line or in a compact unified view. Use it for code review prep, contract redlines, and catching accidental edits before you commit.

Read the full guide →

Frequently Asked Questions

What diff algorithm do most tools use?: Many browser-based diff UIs build on Myers’ diff or similar longest-common-subsequence approaches that minimize edit operations. The goal is readable hunks—insertions and deletions—not necessarily the mathematically shortest patch for every edge case. Library-backed tools may also offer word-level or line-level granularity on top of the same core algorithm.
Unified diff vs side-by-side—which should I use?: Side-by-side is fastest for scanning large blocks where structure is similar; your eyes align paragraphs or functions across columns. Unified diff (one column with +/- lines) is compact, paste-friendly, and matches what version control emits—better for patches, code review comments, and sharing in tickets. Switch views based on whether you are reading or shipping a change.
How should I handle whitespace when comparing?: Turn off ignore-whitespace when whitespace is meaningful—Python, YAML, and some markup break on indentation. Turn it on when comparing prose or minified vs pretty-printed JSON so you see semantic changes. If your diff tool lacks toggles, normalize copies first (e.g. run text through a [JSON formatter](/json-formatter) for structured data) so noise does not hide real edits.
Is comparing code the same as comparing prose?: Same engine, different settings. Code benefits from line-oriented diffs, optional syntax awareness in some editors, and strict whitespace. Prose benefits from word-wrap discipline and sometimes sentence-level diff. For Markdown-heavy content, pair a text diff with [Markdown preview](/markdown-preview) to verify rendered output, since source diffs do not show heading or list reflow.
Why do small edits produce huge diffs sometimes?: Reordering, reflowing hard wraps, or re-encoding line endings (CRLF vs LF) can make every line look changed even when meaning is stable. Long lines moved as a block also explode visually. Normalize line endings, compare at word granularity if available, or use a dedicated structural diff for JSON/XML after formatting.