PK Systems
Text tools

Text Diff

Compare two pieces of text and see what changed. Line or word granularity, live preview, runs entirely in your browser.

Text Diff

Diff


    

What is a text diff?

A diff (short for difference) is a side-by-side report of what changed between two pieces of text. The classic use is in version control — Git, SVN and friends use diffs to show what each commit modified — but the same idea is useful for proofreading edits, comparing legal contracts, spotting small changes in configuration files, or checking that a document survived a copy-paste round-trip intact. This tool computes the diff using a longest-common-subsequence algorithm, the same family of techniques that power git diff.

How to use this tool

Paste the original version into A and the modified version into B. The diff appears live below: green lines (or words) are additions in B, red are deletions from A, plain rows are unchanged. Switch between line and word granularity depending on what you want to see — line diffs are best for code or structured text, word diffs are easier to read for prose where small wording changes matter. Stats above the output show counts of added, removed and unchanged tokens.

When to use line vs word diff

Line diff is the right default for code, JSON, CSV, log files and anything where structure lives at the line level. A single character change shows up as a removed line and an added line — easy to scan, and matches what version control tools do. Word diff shines for prose: it highlights the actual words that changed inside a paragraph, so you can see edits without re-reading the whole text. Avoid word diff on very long documents — the LCS computation gets quadratic and starts to feel slow above a few thousand words.

Frequently asked questions

Is my text uploaded anywhere?
No. The entire diff is computed in your browser. You can confirm by opening DevTools > Network and pasting your texts — no requests fire. This makes the tool safe for diffing private or sensitive content like contracts, code or config files.
How does the diff algorithm work?
It builds a longest-common-subsequence (LCS) table between the tokenised inputs, then walks the table backward to produce an edit script — the same technique introduced by Hunt-McIlroy and used by classic diff. For very large inputs (above ~2,000 tokens on each side) the tool falls back to a naive position-by-position comparison, which is faster but less optimal.
Why does the result look wrong sometimes?
LCS picks the longest common subsequence, which is mathematically optimal but can produce visually surprising results when there are many short repeated tokens (lots of blank lines, repeated words). If you see weird groupings, switch to the other granularity — line diffs and word diffs sometimes break ties differently, and one will usually match your mental model better.
What about whitespace?
Whitespace is significant. Trailing spaces, indentation changes, and CRLF vs LF line endings all show up as differences. If you only care about real changes, normalise both texts (trim trailing whitespace, convert tabs/spaces, unify line endings) before pasting them in.
Can I export the diff?
Not as a unified-diff patch yet — this tool focuses on the visual side-by-side comparison. To export a patch in unified format, run diff -u a.txt b.txt from the command line, or use git diff --no-index a.txt b.txt for a richer output that matches what GitHub shows.
Why are line endings sometimes flagged as changes?
Different operating systems use different line-ending conventions: Windows traditionally uses \r\n (CRLF), Unix and macOS use \n (LF). When text is copied between systems, line endings can mix and the diff will treat line\r and line as distinct. Run the text through a tool like dos2unix or paste through a plain-text editor that normalises endings before comparing.