Compare Text is an online tool that takes two pieces of text and shows you exactly what changed between them. Paste an old version on one side and the new version on the other; differences light up in colour. Green means added, red means removed.
It works for anything plain text — paragraphs of writing, code snippets, configuration files, contract clauses, translations. Lines that match stay neutral, so your eye goes straight to what's different.
Use it when you don't want to open a heavy desktop tool but you do want accurate results in one click. No signup, no upload, and no record of what you compared.
Compare Text takes two pieces of text and highlights what was added in green and what was removed in red. It does the work character-by-character, so a single missing comma or a renamed variable shows up clearly. The engine is Google's diff-match-patch library (Apache 2.0). The general technique is called a diff, and the underlying problem (finding the smallest set of edits between two strings) reduces to the classic longest common subsequence problem.
The engine handles natural language and code equally well — the same kind of approach that powers revision history in document editors. If you're comparing structured data instead of prose, our JSON diff tool parses both sides first and ignores key order — different problem, different tool.
There's no server. Your text is read by JavaScript using the FileReader API, compared in memory, and the result is drawn back into the page. Close the tab and it's gone.
Three steps. The diff updates as you type, so there's no compare button to press.
Paste it into the left panel, or click Upload to load a .txt or .md file. Sample drops in a short example if you just want to see the tool in action.
Paste or upload it on the right. As soon as both panels have content, deletions show up in red on the left and additions in green on the right.
Scroll either side, both panels stay in sync. The header tells you how many changes were detected. Copy or Download either text once you're happy with the result.
Paste V1 of a vendor agreement on the left and the redlined V2 on the right. Indemnity, payment, and termination clauses that quietly changed surface immediately. Useful when the other side sends a clean copy without track-changes turned on.
Compare your draft against an editor's revised version, or your blog post before and after a copy edit. Every word that changed shows up; you don't have to reread the whole piece to find the dropped sentence.
Original on one side, the translator's revisions on the other. Spot which idioms got rewritten and where the editor pushed back on a literal rendering. Saves a second pass through the whole document when you trust the reviewer.
nginx.conf, systemd unit files, .env templates. Two versions, side by side, in seconds. Faster than firing up diff in a terminal when both files are already in your clipboard from a chat thread.
Yesterday's deploy log against today's, or the same job's output from two CI runs. Stable lines fade into the background and the new error pattern stands out. For multi-megabyte logs, narrow to the relevant subset with grep first.
Edge cases this tool surfaces most often, with the reasoning behind them.
| Topic | What this tool does |
|---|---|
| Line endings | LF, CRLF, and CR are distinct characters. A Windows file (CRLF) compared against a Unix file (LF) will look like every line is different. Normalise to LF in both sources, or strip the carriage returns before comparing. |
| Trailing whitespace | Shown as a real difference — the highlight extends past the visible character. Useful for catching trailing spaces in YAML or CSV that quietly break parsers. |
| Unicode normalisation | café with a precomposed é (U+00E9) is one character; the decomposed form e + combining accent (U+0301) is two. They render identically but diff differently. Apply Unicode Normalization Form C with String.prototype.normalize() to make them match. |
| Match granularity | Character-level under the hood, with a semantic-cleanup pass that groups changes at word boundaries when it can. That is why short common words sometimes look matched across otherwise unrelated text. |
| File encoding | Uploaded files are read as UTF-8 via the FileReader API. Other encodings will appear garbled. Convert in advance, or paste from a tool that has already decoded the file. |
| Large inputs | Up to a few hundred KB is sub-second. 1–2 MB feels noticeably slower. Past 5 MB the rendering — not the diff algorithm — becomes the bottleneck. Narrow down before pasting. |
| Empty side | If one pane is empty, the other side shows entirely as an addition (or deletion). That is the diff behaving correctly, not a bug. |
| Identical input | When both sides match exactly — including whitespace, line endings, and Unicode form — there are zero changes and the headers do not show counts. |
No. The whole comparison runs in your browser. Nothing is sent to a server, logged, or stored. Open DevTools and watch the Network tab — there are no outbound requests when you compare. Close the tab and your text is gone.
A text diff compares characters in order, so reordering keys in JSON or reformatting whitespace shows up as differences even when the data is identical. If you're comparing JSON specifically, use the Compare JSON tool — it parses both sides first and is order-aware. For prose, configs, plain code, or anything that isn't structured data, text diff is what you want.
It compares them as-is, so a Windows file (CRLF) pasted against a Unix file (LF) will look like every line differs even when the content matches. That's the diff working correctly — the inputs really are different. To fix it, normalise line endings in both sources first, or strip the carriage returns before pasting.
Practical limit is your device's memory. Texts up to a few hundred KB diff in well under a second. Past 1 MB the browser starts to feel it, mostly because rendering the highlights gets expensive. For huge log files or full-book manuscripts, narrow down to the section you care about first.
Character-level diff aligns short common substrings — the, a, single letters, punctuation — wherever it can. A semantic-cleanup pass groups these into word-level chunks where possible, but two unrelated paragraphs will still produce a fragmented result. The algorithm has no way to know when two pieces of text aren't meant to be compared.
Files uploaded via the upload button are read as UTF-8 (the FileReader default). Files in other encodings — Latin-1, Shift-JIS, Windows-1252 — will appear garbled; convert them to UTF-8 first. For text already in your clipboard, your OS has resolved the encoding before you paste, so it generally just works.