Text Diff

It does not, exactly — the line diff only produces added, removed and unchanged rows. When a removed row is directly followed by an added row, the tool treats that as a changed line and runs a word-level diff over the pair, showing both rows with the differing words highlighted. A deletion and an insertion that are not adjacent stay separate.

For the equality test it collapses every run of whitespace in a line to a single space and trims the ends, so ' foo( a, b )' and 'foo( a, b )' match. The rows still show your original text unchanged; only the matching is affected.

No. It shows the difference between two blocks but never combines them, and it has no three-way mode, no base revision and no conflict resolution. Use it to understand a change, then apply the edit yourself or in your editor or version-control tool.

The line diff builds an n-by-m table, so there are two hard caps: the two inputs together may not exceed 200,000 characters, and the line counts multiplied together may not exceed about four million. Past either one the tool stops and tells you instead of locking up the tab. Diff a smaller section at a time.

The matching rule, not the display: lines are compared after runs of whitespace collapse to one space and both ends trim, so a re-indented or re-wrapped line still counts as unchanged. The rows still show your original text exactly as pasted — the softening lives in the comparison only. It is the option for when one side passed through an editor that reformatted indentation.

Two caps guard an algorithm that builds an n-by-m table over the lines: 200,000 characters combined across both inputs, and about four million table cells from the line counts. Either cap halts the comparison with a clear error instead of freezing the tab. Prose and config files sit far inside both; minified JavaScript — thousands of characters on one line — is the shape that hits the first cap, so pretty-print before diffing it.

Line granularity is the diff's first pass: a line is same, added or removed as a unit. Where a removed line sits directly above an added one, the word-level pass runs over that pair and highlights which words actually moved. If the surrounding context does not line the pair up, the coarse line-level result stays — an accurate statement ('one line replaced another') even where it is not the finest-grained one.

Not directly — it compares the text you paste, and pasted documents bring extractor artifacts: soft line breaks at odd widths, ligatures, curly quotes that differ from straight ones. Export both sides to plain text through the same path, then compare; a diff over differently-extracted sources reports the extractors as much as your edits. For HTML specifically, the HTML-to-Markdown tool gives a cleaner comparison medium than raw markup.

No — a moved block reads as a removal in one place and an addition in another, because the engine tracks same, added and removed only. Move detection is heuristic territory where plausible-looking guesses are easy and wrong; this tool stays with the deterministic core that is exactly correct and leaves interpreting the move to you.

Strict, with no Unicode normalization applied: 'café' written composed and the same word with a separate combining accent are different strings and show as changed. That strictness is exactly right for code and data, where a hidden composed-versus-decomposed pair is a real bug this diff will find; for comparing prose where you suspect only the encoding differs, normalize first, then diff.