Text and Document Comparison

How to use Text Compare

1. Supply the two texts. Paste into the two boxes, or load a file for either side — .txt, .md, .html, .csv and .json files are read as text, on this device. Each input may be up to 1,000,000 characters.
2. Choose a mode. Lines suits documents, configuration files and code; Words suits prose, where a line is a whole paragraph; Characters finds the smallest edits, down to a single letter.
3. Set the options. Tick Ignore case when capitalisation differences should not count, and Ignore whitespace when re-indented or re-wrapped text should compare as unchanged.
4. Compare, then read the summary first. The counts tell you the scale of the change before you look at any detail: how many units were added, removed and left unchanged in the mode you chose.
5. Walk the changes. Use Next and Previous (or the N and P keys) to jump from change to change; the position indicator keeps your place. Switch between side-by-side and unified views at any time — both show the same comparison.
6. Keep or share the result. Copy it, or download a .diff file, a plain-text summary, or a self-contained HTML report. The share-link button encodes both texts into the link itself — anyone who opens it sees the same comparison, so only share it with people who may read the texts. Swapping sides (button or Alt+S) re-runs the comparison in the opposite direction, and Clear both can be undone for ten seconds.

Worked example

The Load sample pair button loads a three-line original — a sentence about a fox, a team meeting on Monday, and an instruction to send a report by Friday — against a revised version in which the fox leaps instead of jumps, the meeting moves to Tuesday, the Friday line is unchanged, and a fourth line, “Thank you for your help.”, is added.

In line mode the verdict is exact: 2 lines removed, 3 lines added, 1 line unchanged. Because the two edited lines sit next to each other, they form a single change block; the appended line is the second block, so change navigation reports 2 changes. Switch to word mode and the same comparison reads differently: 2 words removed (“jumps”, “Monday”), 7 words added (“leaps”, “Tuesday” and the five words of the new closing line), 20 words unchanged. Neither answer is wrong — they count different units, which is the whole point of having modes. These counts were produced by running the computeDiff function from the shipped text-compare.js in Node, with the global Diff set to the vendored diff.min.js (jsdiff 5.2.0) — the same two files, in the same arrangement, that this page loads when you press Compare.

--- Original
+++ Revised
- The quick brown fox jumps over the lazy dog.
+ The quick brown fox leaps over the lazy dog.
- Our team meets every Monday at nine.
+ Our team meets every Tuesday at nine.
  Please send the report by Friday.
+ Thank you for your help.

What this tool does, and why it matters

Two versions of a text always differ in ways the eye is bad at finding. A contract redraft changes one “may” to a “must”; a colleague “tidies” a document and quietly drops a paragraph; a configuration file works on one machine and not another for the sake of one line. Reading both versions side by side and hoping to spot it does not scale, and memory is worse: by page two you no longer trust your recollection of page one. A diff replaces that hope with a procedure. This tool computes the difference with the jsdiff library (version 5.2.0, vendored and loaded from this site — nothing is fetched from a CDN), which implements the Myers algorithm: it finds a shortest sequence of insertions and deletions that turns one text into the other, and presents exactly those, with everything else certified unchanged.

The three modes are three different questions. Line mode asks “which lines changed?” and suits documents, code and data files, where the line is the natural unit of editing. Word mode asks the same question at the granularity prose is actually edited at — invaluable when a word processor has re-wrapped every paragraph, making a line comparison report that everything changed. Character mode is the microscope: it catches the changed digit in a long number, the swapped letters in a name, the one altered character in a licence key. Choosing the mode is choosing what counts as a change, and the summary counts always state their unit so the numbers can never be mistaken for one another.

The two options answer the most common objection to a raw diff: “these are not real changes”. Ignore case folds capitalisation away by comparing case-folded copies and mapping the results back, so the display keeps your original capitals. Ignore whitespace compares whitespace-normalised text, so re-indented code and re-wrapped prose can compare as unchanged. Both are implemented carefully and described exactly in the limitations below — including the one place where the underlying library’s own option proved not to do what its name suggests, and what we did instead.

Finally, the result is built to leave the page. A comparison is usually evidence in a conversation — with an editor, a reviewer, a client — so you can copy the unified result, download it as a .diff file, save a plain-text summary of the counts, or download a complete HTML report that opens anywhere and shows the counts and the marked-up text in one file. And all of it happens in your browser: contracts, drafts and data files are compared on this device and never uploaded.

Common problems, errors and limitations

Size limit. Each input is capped at 1,000,000 characters. An input over the cap is refused with a message naming its size, and nothing is compared; trim the text or split it at a natural boundary and compare in parts. Files are read as text in the browser: .txt, .md, .html, .csv and .json work; Word .docx files are not extracted (save as .txt first), and binary files simply fail to read, with an error saying so.

How “ignore whitespace” really works. In word and character modes, both texts are pre-normalised — every run of whitespace collapses to a single space — and the comparison runs on the normalised text, so the preview reflects that collapsed spacing. In line mode, each line is trimmed and its internal whitespace runs collapsed for comparison, while the display always shows your original lines. We document this because the alternative was not honest: the vendored jsdiff 5.2.0 accepts an ignoreWhitespace option for character diffs but ignores it — we verified this by running the shipped diff.min.js in Node with the option on and off and getting identical output — so character mode uses the same pre-normalisation as the other modes rather than a setting that pretends to work.

How “ignore case” really works. The comparison runs on lower-cased copies, folded one Unicode code point at a time so results map back exactly to your original text (the display keeps your capitals). One honest caveat: folding code point by code point cannot reproduce context-sensitive whole-word rules, such as the Greek capital sigma that lower-cases differently at the end of a word, so a sigma in that one position may be reported as a difference even with Ignore case on.

Counting details. Line endings are normalised (CRLF and CR become LF) before comparing, so the same file saved on Windows and on Mac compares as unchanged. Summary counts count units of the chosen mode — lines, words or characters (Unicode code points) — and in word mode a change that only moves whitespace appears as a change block but adds and removes no words, which the status line points out. If both inputs are empty you get a plain “nothing to compare” message, and if exactly one is empty the other counts in full as added or removed, as you would expect. Very large inputs near the cap, in character mode especially, can take a few seconds: the underlying algorithm’s cost grows with the number of differences, and there is no progress bar — the tab stays responsive, but be patient before pressing Compare twice.

Frequently asked questions