Text Compare

How to read the output

Two line-number columns, then a marker, then the line. The first column is the position in the original, the second in the changed version. A line present in both keeps both numbers and is dimmed. A removed line is tinted red and has a number only on the left; an added line is tinted green and has one only on the right.

That layout is deliberate: when a block shifts because you inserted something above it, the two columns diverge and you can see by how much. A single-column diff hides that.

Why it stays fast

The comparison uses Myers' diff algorithm, the same approach behind git diff. Its cost scales with the size of the difference, not the size of the files, which is the property that matters: two thousand-line files differing in three places are compared essentially instantly, because the algorithm never explores the parts that match.

Before that runs, the common opening and closing lines are stripped, which handles the everyday case where you changed something in the middle of a long file. On this page, comparing two 5,000-line files with twenty changes takes under a millisecond. A pathological case — two files of the same length with nothing in common — is the slow one, and even that stays in the low hundreds of milliseconds. Each side is capped at 20,000 lines.

The naive approach, an LCS table with one cell per pair of lines, needs 25 million cells for two 5,000-line files. That is why tools built that way ask you to upload instead.

The ignore options

• Case — for comparing identifiers or config keys where casing is inconsistent but irrelevant.
• Whitespace — collapses runs of spaces and tabs and trims each line. This is the one to reach for after a reformat, when indentation changed and the code did not.
• Blank lines — drops empty lines from both sides entirely, useful when one version has been through an editor that adds or strips them.

These affect only the comparison. The lines shown are always the originals, so you never lose sight of what the text actually says.

Line endings and the invisible difference

Two files that look identical but refuse to compare equal are almost always a line-ending problem. Windows uses CRLF, Unix uses LF, and most editors do not show the difference. This tool normalises CRLF to LF before comparing, so that particular ghost does not appear here.

A trailing newline is handled the same way — a file ending with a newline and one not ending with a newline are treated as having the same lines, rather than the first appearing to have a phantom empty line at the end. If you specifically need to detect either difference, compare the files' hashes instead: the hash generator will show them as different immediately, because hashing has no notion of insignificant whitespace.

Common questions

Is my text uploaded?

No. The comparison runs in your browser and the page makes no network requests. Worth knowing if the two things you are comparing are production logs or contract drafts. See the privacy policy.

Can it highlight changes within a line?

Not currently — the diff is line-level, so a line with one changed word shows as one removal and one addition. Word-level highlighting is a useful addition and is on the list.

Can I compare two files instead of pasting?

Not yet. For now, open each file and paste. Nothing about the comparison changes.

Why is a moved block shown as a delete and an add?

Because a line diff has no concept of movement — the line is gone from one place and present in another. Detecting moves is a genuinely different algorithm, and the tools that attempt it disagree with each other regularly.

Is the copied diff a valid patch file?

No. Copy gives you the marked-up lines for pasting into a ticket or a message. A unified diff that patch would accept needs hunk headers and file paths, which only make sense when comparing actual files.

• JSON formatterSort keys on both sides first, then diff — the changes stand out.
• Hash generatorConfirm two files are byte-identical, whitespace included.