Text Diff Checker
Compare two texts and instantly highlight every addition, deletion, and change - line by line, word by word, or character by character.
How to use
- Paste the original text into the left panel.
- Paste the new or edited version into the right panel.
- Choose whether to compare by line, by word, or by character.
- Review the coloured highlights: green for additions, red for removals, yellow for changes.
- Toggle case sensitivity or whitespace handling for cleaner diffs.
Frequently asked questions
How does the diff algorithm work?
Under the hood we use a longest-common-subsequence comparison, the same family of algorithms behind Git diffs. It produces minimal, readable changesets for most natural text.
Can I compare large files?
Yes. The tool comfortably handles tens of thousands of lines on a modern device. Very large files may slow rendering since highlights are rebuilt on each change.
Is my text uploaded anywhere?
No. The diff runs entirely client-side so neither input ever leaves your browser.
Can I ignore whitespace or case differences?
Yes. The Options panel includes toggles to ignore leading and trailing whitespace, collapse runs of spaces, and treat upper and lowercase as equivalent.
How a diff decides what changed
Diff algorithms do not compare texts line-against-line; they search for the longest common subsequence... the largest skeleton both versions share... and report everything outside it as additions or deletions. This is why a single inserted paragraph shows as one clean addition rather than marking every subsequent line as different, and also why moved text shows as a deletion plus an addition: classic diff has no concept of movement. Knowing this prevents the common misreading where a relocated block looks like a rewrite.
Choosing granularity deliberately
- Line mode suits code, configuration and any text where lines are meaningful units; it is what version control shows you.
- Word mode suits prose, where a one-word edit should not condemn the whole paragraph.
- Character mode catches the changes the other modes summarise away: a flipped digit in an IBAN, a single-letter name correction, an invisible character. Use it when two strings "look identical" but a system insists they differ... trailing whitespace and Unicode lookalikes are the usual culprits.
Reading unified vs split output
Split (side-by-side) view keeps each version's layout intact and suits careful review of substantial edits on a wide screen. Unified view interleaves removals and additions in one column... denser, better on mobile, and the format of patches and code review tools, so fluency in reading it transfers directly to Git. Practical review workflows that save real time: diffing a contract version against the one you actually approved before signing, comparing config files between a working and a broken environment, and verifying that an "only formatting" commit truly changed no logic.
Preparing texts so the diff tells the truth
Diff quality depends on input hygiene. Comparing a paragraph reflowed at different line widths produces a wall of false changes; normalising both versions (one sentence per line works well for prose) makes real edits stand out. Invisible differences... tabs vs spaces, Windows vs Unix line endings, curly vs straight quotes pasted from different editors... can light up a diff while changing nothing meaningful; if everything looks changed but nothing reads changed, suspect whitespace and punctuation encoding first. And compare like with like: text extracted from a PDF differs from the original source in hyphenation and breaks, so diff two PDF extractions rather than an extraction against a source file.
Advertisement