Compare Two Texts Word by Word

Two versions of a paragraph look identical until a comma moves, a number changes or a sentence disappears. Reading them side by side works for a short email and fails for a two-page proposal. A diff highlights what changed, but the unit of comparison matters: word-level tools catch small edits inside a sentence, while line-level tools are better for code and structured records. The local text diff compares words, and knowing that makes its output much easier to interpret.

Part of the word and text guide. The tool runs in the page and does not store either version. It has no account, no history and no export, so keep the original documents somewhere safe before pasting them.

What a word-level diff shows

The tool splits each version into words and whitespace, then finds the longest common subsequence between the middle sections. Text before the first difference and after the last one is treated as unchanged. The output colors removed words with a strikethrough and added words with a highlight, and reports a count of removed and added tokens.

That design makes small edits visible. Changing 30 days to 45 days highlights only the number. Reordering a clause shows the old words as removed and the new words as added, even though the meaning may be similar. Inserting a sentence produces a long green run, which is easy to spot.

Whitespace is part of the token stream. A changed space, a removed line break or a doubled space can appear as an added or removed token, and the counts include those tokens. That is why the numbers may be larger than the number of visible words you changed. It is not a bug; it is a consequence of comparing raw text.

Example: The plan costs 30 dollars per month. versus The plan costs 45 dollars per month. produces one removed token and one added token. The surrounding words stay unchanged. If the second version also changes the line wrapping, the whitespace tokens can add to the counts even though the prose is identical.

How the comparison works under the hood

After trimming the common prefix and suffix, the tool builds a dynamic-programming table over the remaining tokens. When the table is small enough, it reconstructs an ordered set of matches, deletions and additions. When the remaining block is very large, the table would be too expensive, so the tool skips the detailed alignment and shows the entire middle section as removed followed by added. That fallback is honest but coarse: it preserves the counts and the visible change, not the fine-grained pairing.

The practical threshold is a product of the two middle token counts. A large document with edits at both ends can trigger the fallback even if the changed middle is modest. If the output suddenly looks like two big blocks instead of interleaved words, shorten the input around the region you care about and compare that excerpt.

There is no option to ignore case, ignore punctuation or normalize whitespace. Total and total are different tokens. A curly apostrophe and a straight apostrophe are different characters. If those differences are noise for your task, normalize both versions in a text editor first, then paste the normalized copies.

Reading the counts and the colors

The red count is the number of removed tokens, and the green count is the number of added tokens. They are not a score, and they do not tell you whether the edit is good. A single changed digit can be more important than a rewritten paragraph. Use the counts to confirm that the diff actually ran and to estimate the size of the change, then read the highlighted passage.

Moved text is displayed as a removal in one place and an addition in another. The tool does not detect moves, so a paragraph that was relocated can look like a deletion and an unrelated insertion. For a contract, that difference matters: a moved clause may still be enforceable, while a deleted one may not. Read the context around both colors rather than relying on the summary.

Punctuation attached to a word stays attached. A changed comma may highlight the neighboring word, depending on where the token boundary falls. Numbers with thousands separators can split differently between versions. If the highlighting looks odd, compare the two source sentences directly and treat the diff as a pointer, not a verdict.

When word diff is the right tool

Use it for prose revisions: blog drafts, cover letters, policy summaries, product descriptions and translation checks. It is good at catching a changed date, a dropped negation or a swapped name. It is also useful when a collaborator says “I only made a few edits” and you want to verify that claim before publishing.

Do not use it as a code review tool. Code diffs need line numbers, context, syntax awareness and the ability to ignore whitespace. A word-level view of a JSON file or a function can be unreadable. Use version control for code, and use a line-based diff when you need to review configuration or structured text.

For legal redlines, a word diff is a starting point, not a replacement for a clause-by-clause review. It cannot tell you whether a change alters an obligation, and it does not track comments or authorship. Export the comparison or annotate the source document with a qualified reviewer.

A practical comparison workflow

1. Save both versions with clear names before editing either one.
2. Normalize obvious noise such as line endings or smart quotes if you do not want them in the diff.
3. Paste the original on the left and the revision on the right.
4. Read the first changed passage in context; do not start with the counts.
5. Check names, numbers, dates and negations specifically, since a single token can change meaning.
6. Copy the final approved text back into the source document, not from the diff view.

The tool does not upload either document, which is useful for unpublished drafts and internal notes. It also does not save them, so closing the tab clears the comparison. If you need an audit trail, keep the versions in your document system and record which one was approved.