Text Diff Checker

How this text diff checker compares two versions

A text diff checker doesn't compare your two texts character by character. It first chops each one into lines, then asks a single question: what's the longest sequence of lines that appears, in the same order, in both versions? That's the longest common subsequence, LCS for short. Everything in that backbone counts as unchanged. Whatever's left over in the original got removed, and whatever's left over in the new text got added. Simple idea, surprisingly fiddly to get right.

This tool does it the textbook way. It builds a dynamic programming table where each cell holds the best match length up to that point, then walks back through the table to recover the actual sequence of operations. No heuristics, no fuzzy matching. If a line moved from the top of the file to the bottom, you'll see it as one removal and one addition, because that's literally what happened from a line ordering point of view. Some fancier tools try to detect moves. Honestly, I find the plain version easier to trust.

One thing worth knowing: when a line changes slightly, say a typo fix, a line diff reports it as the old line removed plus the new line added. It can't say "these two lines are 95 percent the same" because it only knows equal or not equal. Character level diffing inside changed lines is a separate, harder problem, and most of the time the red and green pairs sitting next to each other tell you everything anyway.

Diff vs git diff

The classic diff command has been comparing files on Unix since the 1970s, and its unified output format (those - and + prefixed lines) became the lingua franca of patches. git diff speaks the same format but answers a different question. Plain diff compares two files you point it at. Git diff compares snapshots inside a repository: your working tree against the index, one commit against another, a branch against its merge base.

Under the hood git defaults to the Myers algorithm, which finds the same kind of minimal edit script that LCS does, just computed more efficiently for big inputs. Git also ships alternatives like --diff-algorithm=patience and histogram, which sometimes produce diffs that read better for humans even when they're not strictly minimal. This page sticks to the classic LCS approach because for two pasted texts it's exact, predictable, and fast enough. If you need three way merges or rename detection, that's git's job, not a browser textarea's.

When to ignore whitespace

Whitespace noise is the number one reason diffs look scarier than they are. Someone's editor strips trailing spaces on save, or a teammate reindents a block, and suddenly forty lines light up when the actual change is two. Turning on the whitespace option trims the leading and trailing spaces off every line before comparing, so a reindented but otherwise identical line counts as unchanged.

Be careful with it, though. In Python, YAML, and Makefiles, indentation IS the logic. An ignored leading tab can hide the exact bug you're hunting. My rule: keep whitespace significant on the first pass, and only flip the option on when the diff is clearly drowning in formatting churn. Ignore case is handy for things like SQL keywords or Windows hostnames where SELECT and select mean the same thing. Ignore blank lines does what it says: empty lines (or whitespace only lines, when the whitespace option is also on) get dropped from both sides before the comparison runs.

Privacy: your text stays on your machine

The whole comparison happens in JavaScript inside your browser tab. There's no upload, no server side processing, no analytics peeking at the content of the textareas. You could load this page, pull your network cable, and the tool would keep working exactly the same. I've seen people paste production configs with passwords into random online diff sites, and it makes me wince every time. With this one the text physically never leaves the page, but the habit of scrubbing secrets before pasting anything anywhere is still worth keeping.

Frequently asked questions

Does this text diff checker send my text anywhere?

No. The diff runs entirely in your browser with plain JavaScript. There is no backend call, no storage, no logging. Close the tab and the text is gone. If you are skeptical (good instinct), open your browser network panel while you hit Compare and watch exactly zero requests go out.

What algorithm does the comparison use?

The classic longest common subsequence, computed with a dynamic programming table over the lines of both texts, then a backtracking pass that turns the table into added, removed and unchanged operations. It is the same family of approach the original Unix diff is built on. Exact, not heuristic.

Why does an edited line show up as removed plus added?

Because the comparison works at line level. The tool only knows whether two lines are identical, so a one character edit makes the old line removed and the new one added. They sit right next to each other in the output, which in practice makes the change easy to spot anyway.

Can I diff source code with this?

Sure, that is mostly what I use it for. Paste two versions of a config, a script, a SQL dump, whatever. Just be careful with the ignore whitespace option in indentation sensitive languages like Python or YAML, where a shifted indent is a real change and not just noise.

Can I export the result as a patch?

The Copy unified diff button gives you a plain text version with a minus prefix on removed lines, a plus on added lines, and a space on unchanged ones. It is deliberately simple: no hunk headers, no file metadata. Fine for tickets, chat and reviews, but not something you would feed to the patch command as is.