Text Compare

Paste the original in the first box and the revised version in the second, and the panel above the boxes decides how closely the tool looks: Word, the default, marks the exact runs inside a line that changed; Line marks whole lines instead. Under 20,000 characters a side the result updates a quarter-second after you stop typing; past that, a Compare button takes over so a large paste can't freeze the tab mid-keystroke. Everything below is about reading what comes back, and about the handful of jobs this comparison turns out to be genuinely good at beyond the obvious "what changed."

Reading your comparison result

Once both boxes hold something, three figures appear above the diff itself. In Word mode they read Words added, Words removed and Lines changed — the first two count individual word-bearing tokens, the third counts how many lines were touched by any change at all, whether that change was a full rewrite or a single word. In Line mode the same row reads Lines added, Lines removed and Lines changed, and the three figures are disjoint: a line that exists on both sides but differs is counted once, as changed, never also as one added line and one removed line. That distinction matters when you're judging how big an edit actually was — three "lines changed" on a paragraph that was lightly reworded reads very differently from three lines added and three removed, even though a naive diff could describe either case either way.

Below the figures, unchanged lines that run more than eight rows collapse into a single button reading how many lines are hidden, with three lines of context kept visible on each side of the change next to them. Press it and that run expands in place — there's no way to re-collapse it, which is deliberate: once you've looked at a stretch of unchanged text there's rarely a reason to hide it again. On a genuinely long document the diff also stops rendering rows past a point and states the true total in a final line — your device is doing the comparing, and a document that produces thousands of changed rows would otherwise mean thousands of DOM nodes just to display it. Copy diff, covered further down, always includes every row regardless of what's collapsed or capped on screen.

Word diff vs line diff: which granularity to use

Word is the default because it's what most people mean when they ask what changed in a piece of prose — a rewritten sentence shows exactly which words moved, without forcing you to read the whole line to spot a one-word edit. It's the right setting for a draft against its revision, an email against its earlier version, or a paragraph of marketing copy against last week's.

Line is the better setting whenever the line itself is the meaningful unit rather than the words inside it — a config file, a list of environment variables, a block of structured data where a changed line usually means a changed value rather than a changed sentence. It's also the more legible choice on a very dense, punctuation-heavy line, where word-level marking can end up highlighting so many short runs that the marking stops being easier to scan than the raw line would have been. Switching between the two doesn't lose your place or re-paste anything — the row order, the collapsed context and the figures all update to match the new setting on the same two pastes.

Redline comparison for contracts and drafts

Comparing two drafts of the same document — a contract against its redline, a policy against the version legal sent back, a brief against the version a client marked up — is one of the jobs this tool ends up doing best, because it's exactly the shape word-level marking was built for: prose where a small number of words changed inside sentences that are otherwise identical. Paste the earlier draft as Original and the redline as Changed, leave the granularity on Word, and the result reads close to a legal blackline: added language marked in place, removed language struck through, everything untouched left alone around it.

Two things make this more useful for document review than it first looks. Swap exchanges the two panes in one press, which matters because it's easy to paste a document the wrong way round and only notice once you're staring at a diff that reads backwards — added and removed reversed relative to what you expected. And Copy diff turns the result into a plain-text summary with a header stating exactly how many lines were added, removed and changed, which is a fast way to note in an email or a review comment how substantial an edit actually was, without attaching either full document.

Code review without an IDE

Not every code review happens inside a repository. A snippet in a chat message, a function pasted into a support ticket, a "here's what I changed" sent without a diff attached, a fork of a script that's drifted from the original with no shared git history to diff against — all of these are two blocks of code and no tooling around them. That's this tool without any adaptation: paste the before version as Original and the after version as Changed, and word-level marking will pick out the changed identifiers, operators and literals inside otherwise identical lines, which is usually exactly what you're trying to spot in a small code change — a flipped comparison operator, a renamed variable, a changed default value.

Line mode earns its keep here too, particularly on anything indented or structurally dense — the diff body keeps leading whitespace visible and wraps rather than scrolling sideways, so an indentation change inside a nested block still reads correctly even on a long line. Neither ignore option should generally be on for code: whitespace and case are frequently the change in a piece of code, and turning either off — the default — is what keeps the comparison honest about that.

Spotting what changed in a config file

A config file that works in one place and not another is one of the more frustrating debugging sessions there is, precisely because the two files usually look identical at a glance. Pasting the working config as Original and the broken one as Changed turns that glance into an actual answer: a changed value, a renamed key, a line that's present in one file and silently missing from the other, all show up as marked rows rather than something you have to read line-by-line to catch. This applies as much to a .env file listing environment variables as it does to a YAML deployment manifest or a JSON settings file — anything where the file is mostly boilerplate and the one line that matters is easy to miss by eye.

Line granularity is usually the better choice for this job, because in a config file the unit that matters is the whole line — a key and its value — rather than individual tokens inside it. Ignore whitespace, covered below, is worth turning on here specifically: a config regenerated by a different tool or re-indented by an editor can introduce spacing differences that have no effect on how the file behaves, and without that option every one of those lines would show as changed even though nothing about the configuration actually changed.

Ignore whitespace and ignore case: when to turn them on

Both options default off, and that's the honest default: spacing and capitalization are real content until you tell the tool otherwise, and a tool that silently treated a doubled space as invisible would be hiding information you might actually care about. Turn Ignore whitespace on when you're comparing something that's been reformatted, re-indented or regenerated by a different tool since the last version — leading and trailing whitespace is trimmed and any internal run of spaces collapses to one, so a line that changed only in its indentation stops showing as a difference. Turn Ignore case on when you're comparing something where capitalization genuinely doesn't carry meaning — matching against a system that's inconsistent about it, for instance — so that Total and total compare equal.

Whatever you turn on only changes what counts as equal for the purpose of finding differences; it never changes what's shown. A line that only counts as unchanged because of Ignore whitespace still displays with its original spacing intact on screen and in Copy diff — the option affects the comparison, not the text you're looking at.

Copy diff: getting the result out

Copy diff puts a complete unified diff on your clipboard: a two-line header stating the line-level counts and which ignore options were on, followed by every row in the comparison prefixed +, - or two spaces for added, removed and unchanged lines respectively. It's always line-level even when you're looking at word-level marking on screen, because a word-level mark-up can't be expressed faithfully in plain text without inventing a convention nobody reading a pasted diff would recognize — the header says so explicitly rather than silently downgrading the result. It also includes every row regardless of what's currently collapsed or hidden past the render limit on screen, so what you copy is always the complete comparison even when what you're looking at isn't.

That makes it useful anywhere you need to hand the result to someone else without handing over both full documents — pasted into a code review comment, an email summarizing what changed in a contract redline, or a support ticket describing exactly what's different between a working config and a broken one.

Limits: what this tool won't do

A few things this tool deliberately doesn't attempt, so you're not left guessing whether something is broken or simply out of scope. There's no character-level diff — the granularity control is Line and Word only, because splitting text down to individual characters shreds ordinary prose into fragments that read as noise rather than as a clearer signal. There are no line numbers in the gutter, because a number that isn't equally available on a phone and a desktop is a promise the layout can't keep evenly. There's no side-by-side, two-column result — the two input panes sit side by side, but the result itself is always one column, because a word-level change reads better staying inside the sentence it belongs to than split across a gap, and because two synchronized columns simply don't fit a narrow screen. And there's no way to merge, patch or apply a change from one side to the other — this tool reports differences precisely; it never rewrites anything you pasted.