Text diff — compare two texts

How to use it

1. Paste the original text into the first box and the changed text into the second.
2. The comparison updates as you type — additions in green, deletions in red.
3. Switch to line mode if you are comparing code or lists rather than prose.

A diff finds the smallest set of changes, not the edit you made

The comparison is a longest-common-subsequence problem: the algorithm finds the longest run of items appearing in both texts in the same order, and everything outside it is marked added or removed. Intent is never inferred. Move a paragraph and it appears twice - deleted where it was, added where it went - because in order-preserving terms that is the shortest description of the difference.

Granularity then decides what you see. Compared line by line, a line with one changed character is not a modified line at all: old and new are simply two different items, so the whole line is flagged. Word by word, the same edit shows as one word - better for prose, noisier in code, where indentation and punctuation carry meaning a word split throws away.

Line endings and trailing spaces are the classic false positives

Windows editors end a line with a carriage return and a line feed; Unix and macOS use the line feed alone. Neither is visible, and at line granularity every line then differs by one byte - so a file edited on Windows and the same file edited on Linux can diff as entirely changed while being identical in content. Git’s core.autocrlf setting and .gitattributes exist to stop precisely this.

Trailing whitespace is the quieter version. A space at the end of a line is a real byte no editor renders, so it registers as a change and rewrites that line’s blame to whoever last saved the file rather than whoever wrote the code. Hence the trim-on-save setting and the commit hooks that reject it. Watch also for the non-breaking space, U+00A0, which arrives by copy-paste from a word processor and looks exactly like the space it is not.

Questions