Compare two blocks of text or code online and see added, removed, and unchanged lines instantly. A free, private line diff that runs in your browser.
Runs entirely in your browser — your data never leaves your device.
How to use Text Diff Checker
What it does & when you need it
You have two versions of the same thing — a config file before and after an edit, a
paragraph you rewrote, an API response from yesterday and today — and you need to know
exactly what changed. This tool compares the two texts line by line and marks every line
as unchanged, added, or removed. It runs entirely in your browser, so pasting a .env
file, a private schema, or a log full of tokens never sends a single byte to a server.
How to use
Paste the earlier version into the original buffer and the newer one into
changed, or press Sample on the original panel to load a before/after
package.json.
Read the diff panel below. A leading space marks an unchanged line, + marks an
addition, and - marks a deletion. The status bar tallies +added −removed and flags
when the two inputs are identical.
If the differences look phantom, tick Ignore whitespace & line endings to normalise
them away. Press Copy diff or Ctrl/Cmd + Enter to copy the unified result.
Things worth knowing
It aligns lines with a longest common subsequence. The engine treats each side as an
array of lines and finds the longest run of lines that appears in both, in the same order —
the LCS. Those become the unchanged rows; whatever is left over on the original side is a
deletion, and whatever is left over on the changed side is an addition. This is the same
foundation git's diff rests on (git uses Myers' algorithm, an efficient LCS variant), which
is why the output lines up with what you already see in a pull request.
The comparison is by line, not by word. Change a single token and the whole line is
reported as removed and then re-added, because to the algorithm the old line and the new
line are just two different strings. A word- or character-level diff is finer and reads
better for prose, but it is far noisier on code, so line granularity is usually the right
trade-off for source files. If lines were reordered rather than edited, running a
text sorter over both sides first can make the real change obvious.
"Identical but not equal" is almost always whitespace. Two blocks can look the same to
your eye yet differ by bytes you cannot see. The classic culprit is a trailing newline: add
one and the tool reports an added empty final line even though nothing visible moved. The
other is line endings — a file saved with Windows CRLF compared against a Unix LF file
produces a difference on lines that appear blank, because the invisible carriage return
rides along with each line. Tabs-versus-spaces indentation does the same thing. Toggle
Ignore whitespace & line endings to collapse CRLF and CR to LF and strip trailing
spaces before comparing, so you only see edits that actually matter.
Reach for a structural diff when the data is structured. Line-diffing a reformatted
JSON document will bury you in noise the moment keys are reordered or indentation changes; a
JSON diff compares the parsed values instead of the raw text. For plain
writing, pair this with a word counter to gauge how much a revision
actually grew or shrank.
Only the next line changed. React is unchanged, so it stays in the diff as surrounding context.
One word changed in a sentence
The service returns a 200 on success.
Retries use exponential backoff.
=== compare with ===
The service returns a 201 on success.
Retries use exponential backoff.
Turning 200 into 201 marks the whole first line removed and re-added — a line diff does not highlight single words.
Looks identical, isn't
server {
listen 80;
}
=== compare with ===
server {
listen 80;
}
The changed side indents with a tab and has a trailing newline. Enable Ignore whitespace & line endings to make the phantom diff disappear.
Frequently asked questions
How does a text diff tool decide what changed?+
It splits both inputs into lines and computes their longest common subsequence — the longest run of lines that appears in both in the same order. Those lines are marked unchanged; whatever is left over on the original side is a deletion and whatever is left on the new side is an addition. This is the same LCS foundation git's diff is built on.
Why do two texts that look identical still show differences?+
Almost always invisible whitespace. A trailing newline shows up as an added empty final line, and a file saved with Windows CRLF endings differs from a Unix LF file on lines that look blank. Tabs versus spaces do the same. Turn on Ignore whitespace & line endings to compare only the visible content.
Does this compare by line, word, or character?+
By line. Change a single word and the whole line is reported as removed and then re-added, because the algorithm sees two different strings. Line granularity is far less noisy than word or character diffs for source code, which is why most version-control tools default to it.
How do I ignore whitespace or line-ending differences?+
Tick the Ignore whitespace & line endings option in the toolbar. It normalises CRLF and CR to LF and strips trailing spaces and tabs on every line before comparing, so indentation and end-of-line noise drop out of the result.
Is my text uploaded anywhere?+
No. The whole comparison runs in your browser in JavaScript; neither side of the diff is ever sent to a server, so it is safe for configs, credentials, or private code. It also keeps working offline once the page has loaded.