Text Diff Tool

A text diff tool compares two versions of text side by side and highlights the additions, deletions, and changes between them. It is used by developers reviewing code changes, writers comparing document drafts, editors checking revisions, and anyone who needs to understand exactly what changed between two versions of a text.

How to Use the Text Diff Tool

1. Paste the original text into the left panel (labelled "before" or "original").
2. Paste the revised text into the right panel (labelled "after" or "modified").
3. Click the compare button.
4. The tool highlights additions in green, deletions in red, and unchanged text in the default colour.
5. Scroll through the highlighted output to review every change.

The Formula

Text diff tools implement the diff algorithm, most commonly the Myers diff algorithm published by Eugene Myers in 1986, or a variant of it. The algorithm finds the shortest edit script (SES) that converts the original text into the revised text. The edit script consists of three possible operations:

• Insert: a line or character present in the revised text but not the original.
• Delete: a line or character present in the original text but not the revised text.
• Keep: a line or character identical in both versions.

The algorithm solves this by computing the longest common subsequence (LCS) of the two texts. Everything in the LCS is marked as "keep"; everything else is marked as inserted or deleted. Most web-based diff tools operate at the line level for clarity, though some also offer word-level or character-level highlighting for more granular comparison.

Real-World Example

A writer submits a first draft of a product description. Their editor returns a revised version. The writer pastes both versions into the text diff tool. The output shows:

• Deleted (red): "Our product is very good and offers lots of features."
• Added (green): "Our product delivers measurable results across five core categories."

The writer can see exactly which sentences were changed, which were kept, and which were added, without reading both documents in full. They accept the changes that improve clarity and flag two edits for discussion.

Diff in Software Development

In software development, diff is a core concept built into version control systems. The Unix diff command, created in 1974, was one of the first tools to implement text comparison for source code. Git, the most widely used version control system today, uses diff to show changes between commits and between branches. The output format you see in pull requests on platforms like GitHub is a unified diff, which interleaves context lines with added and removed lines using + and - prefixes. Understanding how to read a diff is a fundamental skill for any developer working collaboratively.

Frequently Asked Questions

What is the difference between line-level and word-level diff? Line-level diff marks an entire line as changed if any part of it differs. Word-level diff goes further and highlights exactly which words within a line were added, removed, or changed. Word-level diff is more precise for catching small edits within long paragraphs.

Can I compare code files with a text diff tool? Yes. Code is plain text, so any text diff tool can compare source files. However, specialised code diff tools may offer syntax highlighting and language-aware comparison that ignores formatting differences. For most purposes, a standard text diff is sufficient.

Does the tool handle whitespace differences? Some tools offer a "ignore whitespace" option that treats lines differing only in spaces, tabs, or line endings as identical. This is useful when comparing documents from different operating systems (which use different line endings) or comparing reformatted code.

Can I export the diff output? Most online diff tools allow you to copy the output as plain text or HTML. Some offer a side-by-side view suitable for printing. For a permanent record of changes, copying the unified diff output is standard practice.

Reading a unified diff

The unified format is what Git produces and what the Unix diff command produces when it is given the -u flag. Two short files, one line changed and one line replaced, give this:

--- before.txt
+++ after.txt
@@ -1,4 +1,4 @@
 The quick brown fox
-jumps over the lazy dog.
+jumped over the lazy cat.
 This line is the same.
-Only in the original.
+Only in the revised.

The hunk header reads @@ -1,4 +1,4 @@. The numbers after the minus sign are the starting line and the line count in the original file. The numbers after the plus sign are the same pair for the revised file. This hunk covers four lines of each file, starting at line 1. Lines beginning with a space are context, a minus marks a line present only in the original, and a plus marks a line present only in the revision. The context lines exist so the patch can be applied without re-reading the whole file.

Counting the prefixes back is a useful habit. That example changed two lines and replaced none, so it reads as two removed and two added. The diff between the two versions of the product description further up this page has the same shape: one sentence out, one sentence in.

Line level and word level

This tool compares by line. A single changed word marks the whole line as removed and re-adds the revised version, so the change count reflects lines rather than edits. On the sample the tool loads by default it reports two lines added, two removed and two unchanged, while the same text compared word by word would show one word out and one word in.

| Level | What counts as a change | Best for | | Line | Any difference anywhere inside the line | Code, config files, structured records | | Word | Words added or removed inside a line | Prose, contracts, documentation | | Character | Single characters | Tracking down a typo or a stray space |

The trade is precision against noise. Line level on a reformatted document marks every line as changed. Word level on the same file finds the few words that moved. Character level on a long document produces a result too fine to scan.

Why the algorithm choice shows up in the timing

The longest common subsequence behind the comparison can be found two ways. The textbook method fills a table with one cell for every pair of lines, which costs time and memory proportional to the product of the two line counts, so a 2,000-line file compared against another 2,000-line file needs about four million cells. Eugene Myers published a method in 1986 that walks an edit graph instead, with a running time proportional to N times D, where N is the sum of the two lengths and D is the number of edits in the shortest edit script.

| Method | Time | Memory | Behaviour | | LCS table | O(N x M) | O(N x M) | Steady, predictable, memory hungry | | Myers | O(N x D) | O(N x D), reducible to O(N) | Fast when the two versions are similar |

Myers also showed the algorithm runs in expected time proportional to N plus D squared under a basic stochastic model, and that a refinement of it needs only memory proportional to N. Suffix trees give a further variant at O(N log N + D squared). The practical consequence is that diff tools stay quick on large files because real revisions differ in few places, which is the case Myers optimised for. This tool uses the simpler table method, which suits the text sizes a browser page handles and is the reason the comparison works at line level rather than character level.

The citation is Myers, E. W., "An O(ND) Difference Algorithm and Its Variations", Algorithmica 1 (2): 251 to 266, 1986.

Reading the change count

The tool reports added lines and removed lines above the comparison, and derives a changed count that equals the smaller of the two. A revision that replaced two sentences and inserted a paragraph might add ten lines and remove two, and the changed figure would read two even though ten lines arrived. Treat the pair of counts as the description and the changed figure as a rough label.

Turning a diff into a patch, and ignoring whitespace

A unified diff is an instruction set as well as a report. The patch program reads it from a file and applies it to the original:

patch < changes.diff

The header lines name the files, and the -p flag strips leading directory components from those names, which is how a diff taken at one directory depth applies at another. Git has its own applier, git apply, which reads the same format. Apply a diff to a file that has changed since the diff was made and the program reports a rejected hunk rather than guessing, so a failed patch leaves the original in place beside a reject file.

Whitespace is the most common source of noise. A reformat that only reindents a file marks every line as changed and the comparison becomes unreadable. The Unix diff command offers three ways out:

| Option | Effect | | -b | Treats runs of spaces or tabs as equal when the amount differs | | -w | Ignores whitespace altogether | | -B | Ignores lines that are blank in one file and absent in the other |

Running diff -w on two versions that look different but carry the same words returns nothing at all, which is the quickest way to confirm that a change is cosmetic. The comparison on this page offers no such switch, so a reformatted pair of texts shows every line as changed.

Also try these free tools:

• JSON Formatter
• Find and Replace
• Regex Tester