A diff algorithm needs a unit of comparison — the smallest chunk it's willing to call "unchanged." This tool uses whole lines as that unit, the same choice git diff makes by default. If a single word changes in the middle of an otherwise-identical line, the entire line no longer matches character-for-character, so the whole line shows as one removed line and one added line — not a word-level highlight inside an unchanged line. That's the correct, expected behavior for a line diff; a character- or word-level diff is solving a genuinely different problem and would need a different algorithm underneath.
before: const timeout = 5000 after: const timeout = 8000 → shown as: - const timeout = 5000 + const timeout = 8000
The algorithm: longest common subsequence, not Myers
Under the hood this builds a full dynamic-programming table of the longest common subsequence (LCS) between the two line arrays, then walks it to decide, line by line, whether to emit "unchanged," "removed," or "added." That table is O(n × m) in size, where n and m are the line counts of the two inputs — for two 200-line files that's 40,000 cells, instant on any modern machine. git diff and most production diff tools instead use Myers' O(ND) algorithm, which scales with the number of differences rather than the product of both lengths — meaningfully faster on very large, mostly-similar files. For the paste-box sizes this tool is built for (comparing two API responses, two config files, two versions of a function) the LCS approach is simpler to reason about and plenty fast; it's not a fit for diffing two 50,000-line log files in a browser tab.
Whitespace counts as a real difference
Lines are compared with exact string equality — no trimming, no whitespace normalization. A line that differs only by a trailing space, or by two spaces of indentation instead of four, shows up as a full removed/added pair even though it might render identically. This is the most common source of a diff that looks "wrong" at a glance: pasting the same logical content copied from two different editors or two different indentation settings will show every line as changed, even though nothing meaningful moved. If that happens, it's worth checking whitespace before assuming the content itself diverged.
Why a genuinely empty input isn't treated as one blank line
JavaScript's ''.split('\n') returns [''] — an array containing one empty string, not an empty array. Taken literally, that would make a truly empty input diff as "one blank line," which would show a spurious change if you compare an empty box against a file that also happens to have one genuinely blank line. This tool special-cases a fully empty string as zero lines before diffing, so "nothing pasted" and "one blank line pasted" are treated as the different things they actually are.