Text Diff

Compare two texts and see the differences with character, word, or line-level precision.

100% private

Paste two blocks of text side-by-side and see exactly what changed — line-level adds and removes, with an option to filter the view to only the changed lines. Useful for spotting differences between a draft and an edited version, comparing config files without a git workflow, or auditing what a reviewer actually altered in a manuscript. The diff algorithm runs inside the browser, so you can compare proprietary documents and unreleased copy without anything reaching a server.

Comparison Options
1 lines • 0 chars
1 lines • 0 chars
Runs right inside your browser tab. No uploads. Your files stay private.

How the Text Diff Tool Computes Changes

Text Diff implements the Myers diff algorithm in pure JavaScript — the same algorithm used by `git diff`, GNU diff, and most code review tools. Myers finds the shortest edit script (the smallest number of insertions and deletions) that transforms the first input into the second. The implementation here runs in O((N+M)D) time where N and M are the input lengths and D is the edit distance, which is fast for typical document edits where most lines are unchanged.
A comparison-granularity selector controls how each input is tokenized before Myers runs. Line mode splits both inputs on newline characters and compares the line arrays. Word mode splits on whitespace using the regex /(\s+)/, which preserves the whitespace tokens so the rendered output still matches the original spacing. Character and sentence modes tokenize per character and per sentence respectively. Whichever mode you pick, the diff is computed over those tokens and the changed tokens are highlighted in green or red.
The classic Myers algorithm is O(ND) and uses a V-array indexed by k-line numbers (the diagonal in the edit graph). The implementation walks from start to end finding the furthest reaching point on each diagonal, then back-traces to recover the actual edit script. For typical edits — a few changed lines in a long document — this completes in well under one hundred milliseconds even for thousand-line inputs.
Performance degrades when the two inputs are very different (high D), because Myers explores more diagonals. Pasting two completely unrelated documents and asking for a diff can hit O(NM) in the worst case, which freezes the tab on multi-thousand-line inputs. This is a property of the algorithm, not a bug. For unrelated texts, the result is also not informative.
Whitespace-insensitive and case-insensitive modes do not change the diff algorithm itself; they normalize both inputs before passing them to Myers. Whitespace mode collapses runs of whitespace to a single space and trims; case-insensitive lowercases both inputs. Because the original text is preserved separately, the highlighted output still shows the verbatim characters even when the comparison key was normalized.
Two view modes are available. Unified shows one column with green plus markers for additions and red minus markers for deletions, mimicking the output of git diff. Side-by-side renders the original and modified text in two columns. Both views compute against the same edit script — switching modes does not retrigger the diff calculation, only the renderer. The two input boxes above scroll in lockstep so you can line them up while editing.
Output is exposed via Copy, Download (a plain-text summary where each line is prefixed with +, -, or a space), a JSON report of the summary stats, and a panel that counts added, removed, and unchanged lines. Everything runs synchronously in the browser tab. There is no upload — your contracts, source code, and pre-publication drafts stay local even when computing the diff against a server-fetched template would be more convenient.

Common Use Cases

01

Contract redline review

Compare two versions of a contract clause-by-clause to identify exactly which sentences and definitions changed before re-signing.

02

Code review diff

Paste two snippets of source code and get a Myers-quality line-and-word diff without setting up a Git workflow for casual review.

03

Editorial revision check

Diff two drafts of an article to confirm what an editor changed and whether their edits were applied correctly.

04

Configuration drift detection

Compare a known-good config file against a production version to spot drift, accidental edits, or missing entries.

Frequently Asked Questions

Myers' algorithm, the same one that powers `git diff`, GNU diff, and most code-review tools. It finds the shortest sequence of insertions and deletions that transforms input A into input B. The implementation here is in pure JavaScript, so no external library is loaded — it ships in the page bundle.
The comparison-granularity dropdown controls how each input is tokenized before Myers compares them. Line mode splits on newlines, so the diff highlights whole changed lines. Word mode splits on whitespace, character mode on every character, and sentence mode on sentence boundaries — each gives a progressively finer view of what changed. The displayed text is always the verbatim original; only the tokenization used for the comparison changes.
Yes for typical document edits where most content is unchanged — Myers is O((N+M)D) where D is the edit distance, so a few hundred changed lines in a five-thousand-line file completes in under a second. Pasting two completely unrelated texts produces a near-O(NM) workload and can freeze the tab on multi-thousand-line inputs.
It normalizes both inputs by collapsing runs of whitespace to a single space and trimming each line before passing to Myers. This means trailing-space-only changes and indentation-only changes show as unchanged. The displayed text is still the verbatim original — only the comparison key is normalized.
Line numbers are shown in Line mode only, where they map directly to physical lines. They are tracked separately for each input: an added line gets a new-side number, a removed line gets an old-side number, and an unchanged line gets both, shown in two gutter columns so you can correlate edits with the original document positions. Word, character, and sentence modes do not show the line-number gutter because their tokens do not correspond to line positions.
Yes. The Download button saves a plain-text file where every line is prefixed with + (added), - (removed), or a space (unchanged), which is easy to read or paste into a review. A separate JSON button exports a machine-readable report of the summary stats — added, removed, and unchanged counts, the similarity percentage, and the options used. The text export is a readable summary, not a unified patch, so it is not meant to be applied with `git apply`.
Internally the diff splits on /\n/ which catches LF (Unix and macOS) but treats CRLF (Windows) as a CR character at the end of each line. If your inputs have different line endings, every line will appear modified. Run both inputs through the Text Cleaner first with line-ending normalization on.
No. The Myers implementation runs synchronously inside the browser tab. There is no fetch call and no analytics on the input. You can disconnect from the network after the page loads and the tool keeps working — useful for diffing material under embargo or NDA.
Myers' algorithm does not detect block moves. A paragraph that moves from the top to the bottom appears as one deletion and one addition with the same content. Block-move detection requires a different algorithm (Patience diff or histogram diff with move detection); use a tool like `git diff --color-moved` for that.
Yes. Both inputs are lowercased only for the purpose of computing the Myers comparison key. The displayed text is the verbatim original from each input, so a line that differs only in capitalization will appear unchanged in the gutter but still display its original case.
Maintained by the WebToolVerse teamLast updated Suggest an edit

Advertisement