Text Diff / Compare

Two views, two jobs

Inline is for reading: removed and added lines sit next to each other, and when a line was modified rather than replaced, only the words that actually changed are highlighted. That last part is what makes a one-character change in a long line findable.

Unified diff is for using. It emits the standard format that git apply and patch accept, with @@ hunk headers and three lines of context — so the output is something you can act on, not just look at.

The ignore options

• Ignore case — compares case-insensitively. Useful for prose and config keys.
• Ignore whitespace — collapses runs of spaces and tabs and trims line ends, so a reindent stops drowning out the real change.
• Ignore blank lines — drops empty lines entirely, which helps when comparing output from two formatters.

Line endings are always normalized: a file saved on Windows and the same file saved on Linux will not report every line as changed. That difference is real, but it is never what you opened a diff tool to find.

How the diff is computed

The algorithm is a longest-common-subsequence table — the same foundation as diff(1), without the heuristics that let large diffs run faster at the cost of reproducibility. Given the same two inputs you always get the same alignment, which matters when you are comparing the output against someone else's.

The cost is that time and memory scale with the product of the two line counts, so input is capped at 3,000 lines per side. Past that, the tool says so instead of freezing your tab. For anything larger, git diff --no-index a b is the right tool.

Nothing is uploaded

Both texts stay in your browser. This is the reason to use a local diff rather than a server-side one: the things people most often need to compare — config files, credentials in a .env, a contract, an API response with real customer data — are exactly the things that should not be pasted into someone else's server logs.