Text Compare

How to use this text compare tool

1. Paste the original text on the left.
2. Paste the changed version on the right.
3. Differences highlight instantly, line by line and word by word — switch to "Side by Side" for a two-column view.

How does this comparison work?

Lines are matched using a proper diff algorithm (not just position-by-position), so inserting or removing a line doesn't falsely mark everything after it as changed. Within changed lines, the specific words that differ are highlighted more strongly.

The longest common subsequence — the actual math behind a "proper" diff

A genuinely correct diff algorithm is fundamentally solving what's formally known as the longest common subsequence (LCS) problem — finding the longest sequence of lines that appears, in the same relative order, in both versions of the text being compared. Everything that doesn't belong to that shared longest common subsequence gets marked as either removed (present only in the original) or added (present only in the changed version). This is precisely the mathematical foundation that makes it possible to correctly recognize that a single line was inserted in the middle of a document without that insertion falsely cascading into every single line below it also appearing to have "changed" — a naive line-by-line positional comparison would misreport exactly that kind of cascading, phantom difference, since it would compare original line 5 against changed line 5 directly by position, rather than recognizing that changed line 5 actually still matches original line 4's content, just shifted down by the insertion above it.

Myers diff — the specific, influential algorithm most modern diff tools actually use

The jsdiff library this tool runs specifically implements what's known as the Myers diff algorithm, published by Eugene Myers in a 1986 paper and still, decades later, the dominant algorithm underlying most modern diff implementations, including Git's own default diff engine. Its particular contribution was an efficient way to actually find that longest common subsequence described above by modeling the problem as finding the shortest possible "edit path" through a specific mathematical graph representing every possible way to transform one text into the other, then finding the shortest such path through that graph using a specifically clever, efficient search technique. This approach reliably runs fast enough in practice for real-world, everyday-sized documents, which is exactly why it became the practical, dominant standard across the software industry rather than remaining a purely theoretical algorithm.

Why two equally valid diffs of the same text can sometimes look genuinely different

A subtle but genuinely real fact about diffing: when a document contains duplicate or highly similar lines, more than one minimal, mathematically equally-optimal diff can exist for representing the exact same underlying change — the algorithm has to choose one specific grouping among several that are all technically, mathematically equivalent in overall size. This is exactly why moving a block of text, or making an edit near several duplicate or near-identical lines, can occasionally produce a diff output that looks slightly different, or groups the changes slightly differently, than what you might have intuitively expected as a human reader — both possible groupings are entirely mathematically correct as minimal diffs, but a specific diff algorithm's own particular internal heuristics determine which one it happens to actually present in that specific case.

Beyond code — the many everyday, practical uses of text comparison

While comparing source code changes is the most commonly recognized use case for a diff tool, the exact same underlying comparison technique is genuinely useful across a much wider range of everyday, non-programming situations. Comparing two versions of a legal contract or agreement quickly reveals exactly which specific clauses were modified during a negotiation, without needing to painstakingly read the entire lengthy document twice side by side. Comparing two drafts of an essay, article, or other written document shows exactly what an editor actually changed, beyond simply seeing tracked-changes markup. Comparing two configuration files, two sets of structured data, or two versions of any plain-text document more generally reveals precisely what changed between them, which is genuinely useful well beyond the specific context of comparing programming source code.

Limitations of this tool

This tool compares two blocks of plain text line by line and word by word using the industry-standard jsdiff library — it doesn't compare binary files, images, or other non-text formats, and very large documents (many thousands of lines) may render somewhat slower given the underlying comparison algorithm's inherent computational complexity. It highlights textual differences precisely as they appear, but it doesn't understand the deeper semantic structure of a specific file format (for example, it won't recognize that reordering two otherwise-identical JSON object keys represents no actual meaningful change — for that kind of structural, format-aware comparison specifically for JSON, use this site's dedicated JSON Diff tool instead).