gizmobench

Text Compare

Paste the original into one box and the new version into the other, and the comparison appears as you stop typing: lines that were added, lines that were removed, and lines that were edited shown side by side with only the words that actually moved tinted. Two things separate this from the pages that hold this search. The first is that word-level step inside a changed line, which saves you comparing the line again by eye to find the one word that is different. The second happens before any comparison at all: CRLF, CR and LF line endings are all normalised, so the same file saved on Windows and on a Mac reads as one text rather than as a file where every single line changed. The case and whitespace options change what counts as equal, never the text on screen, and the whole comparison can be copied out as a unified diff.

Two empty boxes.

Word by word inside changed linesLine endings normalised firstBoth texts stay in this browserNo account, no sign-up
View
Case
Whitespace

The original has 1 line and the changed text has 1. The two texts are identical under the options you chose, once line endings are normalised.

The original on the left and the changed text on the right, line by line. Words that moved inside a changed line are tinted.
#Original#Changed
1(blank line)1(blank line)
  • Two identical textsnothing to report
    no changes
  • Windows and Mac endingsnormalised before comparing
    no changes
  • A line repeated three timesone edit, paired the same way every run
    1 changed line

Plain text only: paste the two versions in, or open a file in a text editor and copy it here. Case decides whether "Hello" and "hello" are the same line, and Whitespace decides whether spacing inside a line counts as a difference. Neither option changes the text shown, only what counts as equal. A line over 2,000 tokens is marked as changed as a whole rather than word by word.

Why a word diff, and why line endings come first. Marking a whole line as different when one word moved leaves you doing the comparison again by eye, so every changed pair is compared a second time token by token and only the words that moved are tinted. And before any of that, CRLF, CR and LF endings all become one, because the same file saved on Windows and on a Mac is one text, not a text where every line changed.
Accuracy. Line endings are normalised before comparing, so the same file saved on Windows and on a Mac does not read as changed on every line. Changed lines are compared again word by word. Where lines repeat, more than one alignment is correct, and this one pairs them the same way every time.

Common questions

How do I compare two blocks of text?
Paste the first version into the Original box and the second into the Changed box. The comparison runs by itself a moment after you stop typing, so there is no button to press and no account to make. The result reads in two columns by default, the original on the left and the new version on the right, with a line number for each side: a line both texts hold is plain, a line only the original holds is marked as removed, a line only the new version holds is marked as added, and a line that was edited is shown on both sides with the words that moved tinted. Switch View to Unified for the one-column form, the minus and plus shape a patch uses, and Copy unified puts that block on your clipboard. Swap sides exchanges the two boxes when you realise you pasted them the wrong way round.
What does the word-level highlighting show?
When a line appears in both texts but was edited, the two versions of that line are compared a second time, token by token. A token is a run of word characters, a run of spaces or tabs, or a single punctuation mark, so changing "Tuesday." to "Thursday." tints the day and leaves the full stop alone. The parts that come back rebuild both lines exactly, which means the highlighting can never show you a word that is not in your text: everything untinted is identical on both sides. A line longer than 2,000 tokens, or one that was rewritten rather than edited, is marked as changed as a whole instead, because a word diff of two unrelated sentences is noise rather than information.
Do line endings and trailing spaces count as changes?
Line endings never do. CRLF (Windows), CR (older Mac files) and LF are all normalised to one form before anything is compared, so the same file saved on two different systems reports no changes at all. That is the single most common false result on this kind of page. Trailing spaces are a separate question, and you decide it: with Whitespace set to Compare, the default, a trailing space is part of the line and a line that gained one is a changed line. Set Whitespace to Ignore and runs of spaces or tabs count as a single space and space at either end of a line is ignored, so "a b" and "a b" match. Blank lines are always kept and compared, because in prose a blank line is a paragraph break rather than formatting.
How do I ignore case when comparing?
Set Case to Ignore in the strip under the boxes. "Hello" and "hello" then count as the same line, and inside a line that changed for some other reason a word that differs only in case is not tinted. The option changes what counts as equal and nothing else: both boxes still show exactly what you pasted, upper case and all, and switching back to Sensitive re-runs the comparison on the same text. The two options combine, so Case set to Ignore with Whitespace set to Ignore treats " Hello World " and "hello world" as the same line.
Is my text uploaded anywhere?
No. The comparison runs in your browser, so there is no server in this, no account to make and nothing sent or logged. Both drafts and your three option choices are remembered in this browser alone, so the two texts are still there when you come back, and the Start over button above the tool forgets them. One exception is worth knowing: a text longer than 100,000 characters is still compared in full, but it is not written to storage, so a very large paste is not kept after you close the tab.
Can I compare Word or PDF files?
Not as files. This is a plain text comparison: it reads what is in the two boxes and nothing else, so it has no idea what a .docx or a .pdf contains. Open the document, select the text, and paste it into each box, which is also the comparison most people want, since formatting differences would otherwise swamp the words. The same applies to code and to data: both are plain text, so both compare cleanly here, and a file you have on disk can be opened in any text editor and copied across.
How large a text can I compare?
Up to 20,000 lines or 2,000,000 characters in each box. Those are memory limits rather than a plan: past either one the tool says which box went over, the size it reached and the limit it passed, instead of locking the tab, and suggests comparing a section at a time. Within them, an ordinary edit inside a long document is found exactly. Two texts far enough apart to need more than 1,200 line insertions and deletions to reconcile are lined up in order instead of searched exhaustively, which is both fast and honest, and the line under the boxes says when that has happened. A comparison too large to finish in a moment runs on a background thread inside the same browser, so the page keeps answering while it works, and a run that your next edit has replaced is stopped rather than left to finish. The page draws the first 600 rows of the result, which in the unified view is up to 1,200 lines, because a changed row prints its old line and its new one; Copy unified always writes every row.

Line endings are normalised before comparing, so the same file saved on Windows and on a Mac does not read as changed on every line. Changed lines are compared again word by word. Where lines repeat, more than one alignment is correct, and this one pairs them the same way every time.