Text Diff

1. What is a Text Diff?

A text diff shows the differences between two versions of text. It highlights lines that have been added, removed, or modified, making it easy to see what changed.

This tool provides two viewing modes: a unified view that shows changes inline, and a side-by-side view for easy comparison of corresponding lines.

2. Understanding the Colors

3. What the diff algorithm actually does

A line diff is not magic, and understanding the one idea behind it will save you from the most common misread. The algorithm finds the longest common subsequence— the largest set of lines, in order, that appear in both texts — and treats those lines as unchanged. Everything that is not part of that subsequence is reported as added or removed. The result is the smallest set of edits that turns the left text into the right text, which is exactly what you want when you are asking “what changed?”

This has a consequence that trips up new users. If you reorder a block of lines, the diff does not show a single “reordered” change. It shows the moved lines as removed at their original location and added at their new location, because the longest-common-subsequence search treats them as distinct lines. The same thing happens when you import a function from one file to another: the diff in the second file shows an addition, the diff in the first shows a removal, and the two are not connected. The tool is reporting the truth about what came and went — it just cannot read your mind about why.

For paragraph-length prose, the same algorithm is applied at the word level once lines are shown to differ, so a one-word edit to a paragraph shows up as a single word change rather than the whole paragraph being replaced. For very small edits inside a single line, character-level diffs surface the precise letters that changed. The level the tool shows is chosen so the change is small enough to be readable but large enough that the surrounding context is meaningful.

4. When to use line diff, word diff, and side-by-side

Different inputs reward different views. Source code changes are almost always best read as a line diff, because code is edited line-by-line and most edits touch whole lines. Poetry and prose are usually best read as a word or character diff, because a single replaced word in a long line shows up cleanly at the word level but as a confusing full-line replacement at the line level. Configuration files where one value changed are best read as a character diff so the exact digit or letter that changed is highlighted.

Side-by-side view pays off when you need to read both versions at the same time — for example when comparing two translations of the same paragraph, or two competing drafts of a contract clause, where the question is not “what changed?” but “are these two saying the same thing?” The unified view is faster for “what did the author just do?”; the side-by-side view is better for “how do these two differ in meaning?”

For most code review work, start with the unified line view, switch to side-by-side for the one or two areas where the unified view forces you to scroll, and reach for word or character diff on the specific lines that read as a single confusing replace. Working through one diff that way is much faster than suffering through every line side-by-side from the start.

5. False positives and what they look like

A diff reports what is literally different, not what is meaningfully different. Three common false positives cost reviewers time:

• Whitespace-only changes.A line that has trailing spaces stripped, or that switches from tabs to spaces, will show as a full change even though the rendered output is identical. If you suspect a whitespace avalanche, run both texts through the same formatter first and diff the formatted versions — the result will be the meaningful changes only.
• Line-ending flips. Switching a file from CRLF to LF (common on Windows to macOS moves) flags every line as changed even though no content differs. Normalise line endings on both sides before comparing.
• Reformatted but unchanged code. A prettier run that re-wraps long lines will create a diff that looks large but means nothing. Always compare pre-reformat to post-reformat separately from any meaningful changes you are reviewing.

The fix in every case is the same: identify the cosmetic axis that the diff is reading as change, normalise it on both inputs, and re-diff. The remaining output is the change you actually meant to review.

6. Diff vs “git diff”

git diffis the same algorithm applied to files a version-control system already knows about, with three extra pieces: it ties each change to a commit and an author, it can show changes between any two points in history, and it knows which lines are new versus which were last touched three years ago. This tool is the algorithm on its own — you hand it two texts, it tells you what came and went. For quick comparisons outside a git repo (drafting a contract, comparing two export files, eyeballing two API responses) that is exactly what you want. For tracking the history of code under version control, git diff in your terminal is the right tool, because the change attribution matters as much as the change itself.

7. Privacy First

All text comparison happens directly in your browser. Your data never leaves your device, ensuring complete privacy and security. This matters most for the inputs people forget are sensitive: contracts in negotiation, customer-data extracts being reconciled, credentials and tokens pasted in to debug, configuration files with secrets. None of that touches a server when you compare it here — the work happens in the tab you have open.