When a text diff is the right tool
Some of the most expensive mistakes in software are the ones that look right: a config file that differs from the working version by a single character, a chunk of CSS that a formatter quietly rewrote, generated output that stopped matching its committed baseline. The diff checker is built for exactly these moments. Paste the original and the new version, and the tool highlights every line that was removed and every line that was added, with the unchanged lines between them for context — the same shape of output you get from diff-based review tools, minus the terminal. It is equally useful for documents that never touch a repository: comparing a contract draft to the version you signed, a copied email against the original, a report generated twice. Because everything runs locally, proprietary or personal text never leaves your device, which makes the tool the right choice when the content itself is sensitive.
Reach for this tool whenever “what changed?” is the question and you have both versions in front of you. Typical uses: reviewing a config change before you deploy it, checking what a code formatter did to a file you did not touch, diffing generated output against a baseline to confirm nothing regressed, or proving that two copies of a document are identical. It is also a fast sanity check for copy-paste work — paste the file you think you copied next to the source, and the diff tells you instantly whether you got it right. The tool is deliberately simple: two boxes, one button, one optional checkbox. If your question is about meaning rather than text — which version is correct, whether two JSON documents are semantically equal — this tool answers only the textual part, and judgment is yours for the rest.
One more scenario deserves its own mention: proving that two copies are identical. When a client sends back a “final” version of a contract or a teammate restores a config from a backup, a diff that comes back with every line unchanged is the cheapest proof there is — stronger than a glance, simpler than a checksum, and it leaves the evidence on screen. It also catches the silent regressions nobody files a ticket for: generated output that no longer matches its committed baseline, a minified bundle that changed after a dependency bump, a translated string that quietly reverted to the original language. Run the comparison once, watch the list come back green, and the “is anything different?” question is settled without reading either file end to end. The tool cannot tell you why a difference matters — that is judgment — but it can tell you, to the line, that a difference exists, and that certainty is most of what reviewing a change is about.
Comparing two texts, step by step
Paste the original version into the Original box and the new version into the Updated box — the only two required fields — then click Compare. The result panel opens with a stat grid: added lines, removed lines, and the percentage of lines that changed, plus the full line-by-line list underneath. The Ignore whitespace checkbox sits next to the Compare button; tick it when lines that differ only in leading or trailing spaces should count as equal. That option is the difference between a noisy diff and a useful one when a formatter reindented a file or a paste added stray spaces. Line endings are handled for you: Windows CRLF breaks are normalized to LF before comparison, so a file saved on Windows compares cleanly against one saved on macOS or Linux.
Three pitfalls cover most confusion. First, the comparison is line-based: a single word changed inside a long line shows up as that whole line removed plus a whole line added, never as a word-level edit — so a small change can look like two big ones. Second, reindentation counts as a change unless you tick Ignore whitespace, and even then only leading and trailing spaces are ignored, not spaces inside the line. Third, inputs are capped at 4,000 lines; beyond that the tool trims the input and shows an explicit truncation notice instead of freezing the tab, so watch for the notice when the numbers look small for a very large file. And remember the tool compares text, not meaning — identical text can still be wrong content, and different text can be right.
Reading the diff results
The results panel has two parts. The stat grid shows added and removed line counts plus the percentage of changed lines — that figure is added plus removed divided by the total number of lines shown in the diff, rounded to a whole percentage. Below it, the list renders every line of both versions in order: added lines in green with a plus marker, removed lines in red with a minus marker, and unchanged context lines with a blank marker. Reading the list top to bottom tells the story of the change the same way a code review does: this line left, that line arrived, everything else stayed. After each comparison a summary restates the counts in plain words — “1 added, 1 removed, 3 unchanged” — so you never have to do the arithmetic yourself.
There is little that can go wrong, and the tool surfaces what there is. Comparing two empty boxes yields no added or removed lines and a 0% change figure, and the same is true of two identical files — every line comes back as unchanged context, which is the tool’s most useful answer when you feared a silent difference. Over the 4,000-line cap, a truncation notice appears above the list so you know the numbers cover only the first part of the document — treat those results as partial. The one thing the output never tells you is which version is correct: the diff marks a deleted line and its replacement with equal confidence, so verify intent against the data before you act on the result. That judgment is the part no diff tool can do for you.