Text Diff Checker
Compare two blocks of text line by line and see exactly what changed.
Runs entirely in your browserRelated Tools
How a Diff Decides What Changed
Comparing two texts sounds trivial until you try it. If a line is inserted near the top, a naive line-by-line comparison declares every subsequent line different, because everything shifted by one. That output is technically correct and completely useless.
Real diff algorithms solve this by finding the longest common subsequence— the largest set of lines that appear in both texts, in the same order, though not necessarily adjacent. Everything in that set is unchanged; everything else is an insertion or a deletion. The result matches what a human would say changed.
This is the same idea behind git diff and the diff command, and it is why inserting a paragraph shows up as one added block rather than a hundred modified lines.
The Two Options, and When They Matter
Ignore whitespacecollapses runs of spaces and tabs and trims line ends. Turn it on when comparing code that has been reformatted, or text that has passed through an editor with different indentation settings. Turn it off when whitespace is meaningful — Python, YAML, Makefiles, and Markdown all care.
Ignore case is useful for comparing configuration keys, SQL, and anything where capitalisation is inconsistent but irrelevant. Leave it off for prose, where a capital letter usually means something.
One thing neither option catches: invisible differences. A file with Windows line endings compared against one with Unix line endings can look identical while differing on every line. Trailing spaces behave the same way. If two texts look the same but the diff disagrees, that is almost always why.
Technical notes
- Granularity: line level. A one-character change shows as a removed line plus an added line, which is also how
git diffpresents it by default - Algorithm: longest common subsequence via dynamic programming
- Limit: 3,000 lines per side, because the comparison table grows with the product of both lengths
- Display: the normalised text is used for comparison, but the original text is what you see — so ignoring whitespace does not hide the actual content
- Privacy: nothing is transmitted, which matters when diffing configuration or unreleased content
Reviewing Text You Did Not Write
The most valuable use of a diff is checking what changed in something you are about to accept. A contract returned from the other side, a configuration file after an automated tool touched it, a translation returned from a supplier, a document that went through several rounds of edits — in each case reading the whole thing again is slow and unreliable, while a diff shows exactly the lines that moved.
It is also the fastest way to answer the question “did anything actually change?” A summary of zero added and zero removed lines is a definitive answer that skimming cannot give you.
FAQ
Why is a small edit shown as a whole line changed?
Because this is a line-level diff. Changing one word marks the old line removed and the new line added. It is the same behaviour as the standard diff command, and it keeps the output predictable.
The texts look identical but the diff shows differences.
Almost always invisible characters: trailing spaces, tabs versus spaces, or Windows line endings versus Unix. Turn on “ignore whitespace” to confirm that is the cause.
Is my text uploaded?
No. The comparison runs in your browser, so pasting configuration files, contracts, or unpublished drafts is safe.
Can I compare two files instead of pasting?
Not directly — paste the contents into the two boxes. For file-to-file comparison, diff on the command line or your editor’s built-in compare view is better suited.
Why is there a line limit?
The algorithm builds a table sized by both inputs multiplied together, so very large texts would exhaust browser memory. Three thousand lines per side keeps it responsive.
Can I compare code with this?
Yes. Line-level diffing is exactly how code review tools work. What this does not do is understand syntax, so a reformatted file shows as heavily changed even when the logic is identical — turning on ignore whitespace helps in that case.
Does the order of the two boxes matter?
Yes. The left box is treated as the original and the right as the changed version, so swapping them turns additions into removals.
Can I compare two versions of a JSON file?
Yes, though formatting differences will dominate the result. Running both sides through the JSON formatter first makes the diff show real changes rather than whitespace.
Does it show what changed within a line?
No — this is a line-level diff, so a modified line appears as one removal plus one addition. That is also how the standard diff command behaves by default.
Why is there no character-level highlighting?
Line-level output stays predictable and matches what version control tools show by default. Character-level highlighting looks precise but becomes noisy on reformatted text, where almost every character technically moved.
Can I diff two versions of a translated document?
Yes, and it is one of the better uses. Reviewing what a translator changed between revisions is far faster than reading both versions, particularly for long legal or technical text.
⚠️ Reference Only
Output is generated based on your input and is provided for reference. Results may vary depending on your specific use case, edge cases, or environment-specific behavior. We do not guarantee accuracy of conversions, validations, or computed values.
Always verify critical outputs against official documentation or production environments. We are not responsible for any decisions or losses based on these tool results.