8 min read · updated August 2, 2026
Text Diff: Compare Two Texts Without Missing an Edit
Text Diff
Compare two texts side-by-side — free, no signup
A text diff tool compares two versions of a text and marks every insertion, deletion, and change, so you see exactly what happened between draft one and draft two. That sounds trivial until you have tried to spot a single changed number in a fourteen-page services agreement by eye, or to figure out which line of an nginx config a colleague edited before the server stopped answering. A diff makes the change set explicit instead of leaving it to human attention, which is unreliable at precisely this kind of task.
The tool page covers what buttons to press. This guide covers the part that actually determines whether your comparison is trustworthy: how diff algorithms decide what counts as a change, when character, word, or line granularity is the right choice, and the handful of invisible characters, such as line endings, smart quotes, and trailing spaces, that can make two identical-looking texts diff as almost completely different.
Why eyeballing two versions fails
Human reading is built for comprehension, not comparison. When you scan two documents side by side, your eyes sample the text rather than checking it token by token, and your brain helpfully fills in what it expects to see. That is why a counterparty can return a contract with a cure period quietly changed from thirty days to ten, buried in a clause you have read five times, and you still sign it. The edit is small, the surrounding sentence is familiar, and familiarity is exactly what defeats manual review.
The same failure shows up outside legal work. A CMS strips em dashes on paste and nobody notices until the article is live. An editor tightens a paragraph and accidentally deletes a source attribution. A teammate hand-edits a YAML file on the server and the repo copy no longer matches production. In each case the question is identical: what exactly is different between these two texts? A diff answers that question exhaustively. Every token in both versions is accounted for as unchanged, inserted, or deleted, so nothing can hide in a paragraph you skimmed.
How a diff algorithm finds the changes
A diff runs in two stages. First the text is tokenized: split into units of comparison, which can be lines, words, or individual characters. Then the algorithm searches for the longest common subsequence, the longest run of tokens that appears in both texts in the same order, though not necessarily adjacent. Everything in the old text that falls outside that shared backbone is a deletion; everything in the new text outside it is an insertion.
Most practical tools implement a variant of the Myers algorithm, published in 1986, which finds the shortest edit script: the minimal set of insertions and deletions that transforms text A into text B. Its running time is proportional to the length of the texts multiplied by the number of differences, which explains a behavior you can observe directly: two nearly identical ten-thousand-word documents diff almost instantly, while two heavily rewritten versions of the same document take noticeably longer, because the edit distance itself is what the algorithm has to explore.
Two consequences of this design are worth knowing when you read results. There is no native concept of a modification: a changed word is represented as a deletion immediately followed by an insertion, and the tool renders that adjacent pair as a modified region. And because the common subsequence must preserve order, a paragraph that was moved from page two to page six appears as a deletion in one place and an insertion in another, not as a move. That is not a bug; it is the algorithm telling you the truth within the vocabulary it has.
Character, word, or line: choosing granularity
Granularity decides what a single token is, and picking the wrong one produces diffs that are technically correct but useless to read. A character-level diff of a rewritten paragraph is a wall of fragmented red and green. A line-level diff of prose flags an entire paragraph as changed because one word moved and the lines rewrapped.
A reasonable default: word level for prose, line level for anything structured, character level only when you need to pinpoint an edit inside a token.
- Line level: code, config files, CSV exports, SQL, and anything where a line is the meaningful unit. This matches what git and most code review tools show, so the output reads familiarly.
- Word level: contracts, articles, emails, and marketing copy. Word tokens survive paragraph rewrapping, so the diff highlights the actual edits instead of every reflowed line.
- Character level: part numbers, IBANs, API keys, dates, and URLs, where a one-character change is the entire story. Also the right choice for text in languages written without spaces, where word tokenization has nothing to split on.
Where a diff tool earns its keep
These are the situations where I reach for a browser diff rather than trusting my eyes or someone else's change tracking.
- Contract redlining: paste your last draft against the returned version instead of relying on tracked changes, which the other side can accept, reject, or simply turn off before sending the file back.
- Config drift: compare a config dumped from the production server against the copy in your repo before deploying, so you find the hand-edit someone made at 2 a.m. before it finds you.
- Editorial review: diff the draft you filed against the version that was published to see precisely what an editor cut, softened, or rephrased.
- Terms-of-service monitoring: diff the current terms of a service you depend on against the copy you saved when you signed up, instead of rereading nine thousand words looking for the change the update email did not specify.
- Translation QA: compare a reviewer's corrected translation against the raw machine output to see what a human actually had to fix, which is the fastest way to judge whether the machine output is usable for your content type.
- AI-assisted editing: paste your original text against what a language model returned. Models asked to fix grammar sometimes also alter names, figures, or quoted material, and a word-level diff catches that in seconds.
When two identical texts diff as different
The most common support question about any diff tool is some version of: these texts are the same, why is everything highlighted? The answer is almost always invisible characters. Windows tools end lines with CRLF while macOS and Linux use LF, so a file that crossed operating systems can show every single line as changed when the visible content is untouched. Text copied out of Word or a web page often carries non-breaking spaces where normal spaces should be, curly quotes where straight quotes were typed, and trailing whitespace at line ends. Accented characters can be encoded two ways in Unicode, as a single composed character or as a base letter plus a combining accent, and the two forms diff as different even though they render identically.
When a diff looks absurdly noisy, suspect one of these before suspecting the algorithm. Pasting both texts through the same editor, or retyping the suspicious region, usually normalizes the invisible differences and collapses the noise to the real edits.
One boundary worth respecting: if both versions of a file already live in version control, use git diff, which knows the file history and integrates with review tooling. A browser-based diff is for the enormous category of text that never touches a repo: contracts, emails, CMS content, form letters, meeting notes, and anything a non-developer colleague sends you two versions of.
Common questions
Text Diff FAQs
- How do I compare two texts for differences?
- Paste the original text into one pane of a diff tool and the revised text into the other, then run the comparison. The tool aligns the two versions, marks insertions and deletions in color, and renders adjacent delete-insert pairs as modifications. For prose, compare at word level; for code or config files, compare at line level.
- What is the difference between character, word, and line diff?
- The level sets the smallest unit the algorithm compares. Line diff treats each line as one token and suits code and structured files, word diff treats each word as a token and suits prose, and character diff compares letter by letter, which pinpoints tiny edits inside identifiers, dates, or serial numbers but becomes unreadable on heavy rewrites.
- Why does my diff show everything as changed when the texts look identical?
- Invisible characters are almost always the cause. Mismatched line endings between Windows and macOS files mark every line as different, and text copied from Word or the web often carries non-breaking spaces, curly quotes, or trailing whitespace. Normalizing both texts in the same editor before comparing usually collapses the noise to the genuine edits.
- Is a text diff tool safe for confidential documents?
- It depends on where the comparison runs. A client-side diff tool performs the entire comparison in your browser with JavaScript, so the text never leaves your machine, which matters for contracts and unpublished work. ToolDoor's Text Diff runs client-side; if you use another tool, check whether it uploads your text to a server first.
- Can I compare two Word documents with a text diff tool?
- Yes, by copying the text out of each document and pasting it into the diff panes. You lose formatting comparison, so a change from plain to bold text will not show, but every wording change will. Watch for smart quotes and non-breaking spaces that Word inserts, since they can create noise until both texts are normalized.
- What is a unified diff patch file?
- A unified diff is a plain-text format that records changes as blocks of context lines with removed lines prefixed by a minus sign and added lines by a plus sign. It is the standard interchange format for tools like git and patch, so exporting a comparison as a unified diff lets you apply the changes programmatically or attach a precise change record to a review.
The habit worth building is simple: whenever two versions of anything important exist, diff them instead of trusting your memory of what changed. The algorithm checks every token so you do not have to, and the ten seconds it takes has a way of paying for itself the first time it surfaces an edit nobody mentioned.
ToolDoor's Text Diff tool is free, requires no signup, and runs the entire comparison in your browser, so the texts you paste never leave your machine. Paste both versions, pick your granularity, and read the actual change set.
Nearby doors