About Text Diff
Text Diff compares two pieces of text and highlights what changed — additions in green, deletions in red, unchanged context kept in place. Switch between line-level, word-level, and character-level granularity depending on whether you're comparing two paragraphs, two code snippets, or two near-identical sentences. The diff is computed locally with the Myers diff algorithm — the same one git uses — so even large inputs render fast. Useful for proofreading two drafts of a doc, reviewing config-file changes, or checking what changed between two API responses.
- No uploads
- Browser-only
- Works offline
- 100% free
How it works
- 1
Paste the original and the new version
Drop the 'before' text in the left pane and the 'after' text in the right pane. Drag-and-drop two .txt files to load them side by side.
- 2
Pick a granularity
Line mode is the default and reads like a git diff. Word mode is great for prose. Character mode catches a single letter or punctuation change — useful for hunting a typo.
- 3
Review the inline diff
Removed segments are red with a strikethrough, added segments are green. A summary bar shows additions/deletions/unchanged counts so you can spot the magnitude of change at a glance.
What a diff is really for
A diff answers one question precisely: what changed between version A and version B? Reading two documents side by side and trying to spot edits by eye is slow and unreliable — the human visual system is built to skim, not to audit. A diff inverts that: it ignores everything that stayed the same and surfaces only the insertions, deletions and changes, so a single reworded clause in a 40-page contract or a one-character typo in a config file becomes impossible to miss.
The technique behind it is decades old and well understood — the longest-common-subsequence approach popularized by the Unix diff utility (see the GNU diff manual at gnu.org). What matters in practice is choosing the right granularity: line-level or character-level.
Line diff vs character diff
| Line diff | Character / word diff | |
|---|---|---|
| Unit of comparison | Whole lines | Individual characters or words within a line |
| Best for | Source code, config files, logs, structured text | Prose, headlines, a single edited sentence |
| Shows | Which lines were added, removed, or replaced | The exact letters that changed inside a line |
| Weakness | A one-letter change marks the whole line as changed | Noisy on large structural rewrites |
| Typical question | Which functions did this commit touch? | Did they change 'shall' to 'may' in clause 7? |
The jobs people actually use diff for
- Code review: line diff is the native language of pull requests. It shows precisely which lines a change adds or removes so a reviewer can reason about the smallest possible unit instead of re-reading the file.
- Contract and policy redlines: paste the old and new version to catch every altered word — a "must" quietly softened to "should", a number nudged, a carve-out inserted. Character/word diff is what makes a single-word legal change visible.
- Catching unintended edits: ran a find-and-replace or an automated cleanup and want proof it touched only what you meant? Diff the before and after — anything you didn't expect lights up immediately.
- Reconciling two copies: two people edited the same notes; the diff tells you exactly where they diverged so you can merge by hand with confidence.
What diff can't do for you
A diff is not a merge tool. It tells you what differs; it does not decide which version wins or combine them for you — that judgment stays human. It also has no semantic understanding: reformatting code, reindenting, or reordering two independent paragraphs can produce a large, alarming diff even though the meaning is unchanged. That's a presentation artifact, not a real change.
Whitespace is the classic source of phantom diffs. Mixed line endings (CRLF vs LF), tabs swapped for spaces, or trailing whitespace will flood a line diff with differences that aren't substantive. If a diff looks far noisier than the edit warranted, normalize both sides with Text Clean first, then compare again — the real changes usually shrink to a handful of lines. For two long files where you only want the unique lines rather than a positional comparison, Remove Duplicate Lines is the better fit.
Related guides
All guidesFrequently asked questions about Text Diff
Is it git-compatible — can I export a unified diff?
The on-screen view is inline (side-by-side) rather than unified-diff text. If you need a patch file to apply with `git apply`, save your two versions to actual files and run `git diff --no-index a.txt b.txt`. This tool optimises for reading and reviewing changes visually, not for generating patches.
Which algorithm is used?
Myers' O((N+M)D) diff algorithm — the same one git ships. It minimises the number of edit operations, which is what makes the output read naturally instead of looking like a giant block of deletes followed by a giant block of inserts. For very long inputs (tens of thousands of lines) the heuristic-bounded variant is used to keep the computation fast.
Does it ignore whitespace changes?
Toggle the 'ignore whitespace' option to treat 'foo bar' and 'foo bar' as equivalent — useful when you only care about real content changes and not reformatting. For end-of-line normalisation (CRLF vs LF), run the input through Text Cleaner first so the diff doesn't flag every single line as changed.
Privacy, offline use, browser support, and pricing questions are answered on the site-wide FAQ.