Text Diff

How the Text Diff Tool Works

Paste your original text in the first box and your modified text in the second. The tool compares both versions line by line using the Longest Common Subsequence (LCS) algorithm — the same method used by Git and professional diff tools.

Green lines (marked with +) are additions in the modified text. Red lines (marked with −) are deletions from the original. Switch between Inline and Side-by-side views depending on your preference.

Why Text Comparison Matters

Text diff tools are foundational to software development. Git uses diff algorithms at its core — every commit, pull request, and code review is built on the ability to compare two versions of a file and highlight exactly what changed. Without this capability, collaborative development would require manually reading entire files to spot changes, which is practically impossible on large codebases. The Myers diff algorithm, published in 1986 by Eugene Myers, is the most widely used — it finds the minimum number of edit operations (insertions and deletions) needed to transform one text into another, producing the most readable and intuitive diff output.

Beyond code, text comparison is essential across many professional fields. In legal work, lawyers use diff tools to track contract revisions — spotting a single changed clause in a 40-page document is critical, and a diff makes it instant. Academic integrity systems compare student submissions against source material. Translation teams use diff to check that revised source text is reflected in all language versions. Content editors compare drafts to ensure no unintended changes slipped through. Anywhere two versions of a document exist and accuracy matters, a text diff tool saves time and prevents costly errors.

How to Read a Diff Output

Green lines marked with a plus sign (+) represent content that was added in the modified text. Red lines marked with a minus sign (−) represent content that was removed from the original. Lines with no color or marker are unchanged and appear in both versions. In side-by-side view, the original appears on the left and the modified version on the right, with each changed line aligned to its counterpart — this layout is best for reviewing long documents where you want to read both versions in context. Inline view collapses both into a single column, which is better for small, focused changes where the context of surrounding lines is sufficient.

Here's a tip that's easy to overlook: when reviewing a contract revision or any legal document, look at the red (removed) lines first. What was taken away is often more significant than what was added — a removed liability clause, a deleted warranty provision, or an absent deadline can have major consequences. Similarly, when reviewing a code pull request, removed lines often reveal the intent of a change more clearly than the new lines alone. The diff is symmetric — swap the inputs to see the change from the other direction.

Frequently Asked Questions