Skip to content
← Back

Text Diff Tool - Online Text Comparison

Text
Runs locally · Not uploaded

Online text diff comparison tool: uses LCS algorithm to compare two texts line by line, highlighting additions, deletions, and modifications. Powered by Monaco DiffEditor with syntax highlighting.

Was this result helpful?

For local tools, open DevTools → Network and search your input — it should not appear in requests.

Usage Guide

Where exactly do two texts differ? Scanning line by line is slow and unreliable. This tool compares by line, highlights additions and deletions side by side, can ignore leading/trailing whitespace or case, and shows add/remove/modify/unchanged counts — for comparing config versions, checking code output before and after, or reviewing translated drafts. Everything stays in the browser.

1. Compare two texts

  1. Old text on the left, new on the right — or load the sample to see highlighting first.
  2. Differences highlight in the Diff view; adds, deletes, and same-line modifications are counted separately.
  3. Switch between side-by-side and stacked layouts. Keep "ignore whitespace" off when whitespace is semantic (YAML, Python); turn it on for prose or logs. "Ignore case" helps when config keys are case-insensitive.

2. How to read a diff

A diff shows a minimal edit path, not the author's actual sequence of changes — the same edit can render in several equivalent ways. Read hunks (contiguous add/delete groups) first, single lines second: a "3 deleted + 3 added" hunk is often just a renamed parameter. For very long files, scan hunk distribution and the top-line stats first, then read closely.

3. It is not git diff

  • This compares pasted snapshots, built for "two texts in hand"; for file history across commits, use git log -p.
  • Line diffing is syntax-unaware: reformatting one long JSON line into many creates a sea of noise — format both sides first (see the JSON formatter), or use the json-diff tool for structural comparison.
  • Both panes default to plaintext highlighting; for structural meaning, normalize formats before diffing rather than hoping the editor guesses a language.

4. Choosing diff algorithms and granularity

The classic text-diff algorithms are Myers (what Git uses) and LCS dynamic programming — the former saves memory, the latter is simpler to implement. Engineering-wise, granularity matters more: line-level diff reads best for config files; character-level suits prose revision; word-level sits between. This page is primarily line-aligned and rendered with Monaco Diff — the same "lines first, hunks second" habit as most code-review tools. Note that diff output is not unique: two texts may admit several equally minimal edit paths; different algorithms emit different but equally correct patches, so do not be surprised when two diff tools disagree.

5. Semantic layers when diffing config files

  • Format JSON/YAML before diffing: key-order and indent noise drown real changes; for order-insensitive compares, sort/pretty both sides first.
  • "Ignore whitespace" is a coarse diff -w: leave it off for indent-sensitive languages; turn it on for logs and prose.
  • Noisy timestamp or build-id lines are best trimmed by hand or preprocessed — this page does not ship regex ignore rules. Cutting noise before comparing is usually faster than reading a full screen of highlights.

6. How this splits work with json-diff

Text diff treats both sides as sequences of string lines; json-diff treats them as data structures, so key order and whitespace usually stop creating false diffs. Prefer json-diff for API payloads, config objects, and nested field changes; prefer this page for logs, prose, non-JSON configs, and patch readability. Formatting both sides to readable form first is the shared prerequisite.

FAQ

Ignore leading/trailing whitespace, ignore case, a toggle between side-by-side and stacked layouts, plus add/remove/modify/unchanged line counts. The view uses Monaco DiffEditor for line-level differences.

Turn it on for logs and prose to filter out meaningless spacing noise; keep it off for YAML, Python, and anything where indentation carries meaning. "Ignore case" suits case-insensitive config keys. Noise lines from timestamps or build numbers have no built-in ignore rule — trimming them before comparing is usually faster.

A diff shows the minimal edit path, not the author's actual process — the same change can have several equivalent renderings. Read contiguous add/delete blocks before single lines: a "3 deleted + 3 added" block often boils down to one renamed parameter. For very long files, skim the highlighted-block distribution and the top-line counts first, then zoom into a region.

No. This page compares the two snapshots you paste; for file history and commit-by-commit evolution use git log -p. Line-level comparison is also syntax-blind — splitting one long JSON line into several creates a flood of differences, so normalize both sides with a JSON formatter first or go straight to json-diff.

This page treats both sides as sequences of text lines; json-diff treats them as data structures where key order and whitespace usually stop producing false differences. Prefer json-diff for API payloads, config objects, and nested-field changes; prefer this page for logs, prose, and non-JSON configs. The shared first step is formatting both sides into a readable state.

Comparison runs entirely in browser memory and neither text is transmitted to any server. When handling code or secrets, just watch the secondary paths — screen sharing and downloaded files.

Related Tools

Related Articles