Text diff checker
Compare two versions of text or code and see exactly what changed, line by line.
Spot the differences instantly
Paste the original text on the left and the changed version on the right, then tap Compare. Added lines are highlighted in green, removed lines in red, so the changes jump out instead of forcing you to read both versions side by side. It uses a line-by-line longest-common-subsequence diff — the same core idea behind the diffs in version control — and runs entirely in your browser, so confidential text stays on your device.
When a diff saves you
A diff is the fastest way to answer "what actually changed?" — between two drafts of a document, two versions of a config file, two copies of a contract, or a chunk of code before and after an edit. The human eye is bad at catching a single altered word in a wall of text; a diff finds it immediately. It's also a quick sanity check before sending: paste your edited version against the original to confirm you changed exactly what you meant to and nothing more.
Reading the result
Because this is a line-based diff, it compares whole lines rather than individual words — a line with one changed character shows as a removed line and an added line. That keeps the output simple and predictable, and it matches how most code review tools work. For the cleanest results, paste text that's already broken into lines (paragraphs, list items, code) rather than one long run-on block. To reshape text before comparing, the text transformer can normalise case and whitespace.
How a diff decides what changed
The comparison uses a longest common subsequence algorithm: it finds the longest sequence of lines that appears in both versions in the same order, treats those as unchanged, and marks everything else as an addition or a removal. That is the same core idea behind the diffs in Git and other version control systems.
One consequence is worth knowing: a diff has no concept of a line being "moved". Cut a paragraph from the top of a document and paste it at the bottom, and you will see it once as a removal and once as an addition, not as a relocation. Similarly, a single edit near the start can shift every following line and produce a much larger diff than the change deserves.
Line-based comparison and its blind spots
Because the unit of comparison is a whole line, changing one character marks the entire line as changed. That is usually what you want for code and configuration, where a line is a meaningful unit, but it is unhelpful for prose written as long unwrapped paragraphs — editing one word in a 400-word paragraph flags the whole thing.
- For prose, break the text into shorter lines first, or compare sentence by sentence, so changes localise.
- Reformatting the whole file — changing indentation, wrapping, or line endings — produces a diff where everything changed, which buries the real edits.
- Trailing whitespace and invisible differences in line endings (Windows CRLF versus Unix LF) can make identical-looking lines compare as different.
What it is good for
The everyday uses are catching an unintended edit before sending a document, seeing exactly what a collaborator altered in a contract or brief, comparing two configuration files that behave differently, and checking whether two lists actually match.
It all runs in your browser, which matters more here than for most tools — the text people compare tends to be exactly the sort they should not paste into a random website: contracts, credentials, configuration and unreleased copy. Nothing is uploaded. To normalise formatting before comparing, the JSON formatter and SQL formatter put both sides into a consistent shape first, which strips out noise from the diff.