Why text comparison is one of the oldest computer-science problems
Comparing two pieces of text and showing what changed is a problem that's been studied since the 1970s. The Hunt-McIlroy algorithm, the basis of nearly every diff tool you've ever used, including this one and git diff, was published in 1976 at Bell Labs. It works by finding the longest common subsequence (LCS) between the two inputs, then marking everything outside that subsequence as either "added" (only on the right) or "removed" (only on the left).
Five decades later, the conventions haven't changed. Red for removed, green for added. Side-by-side or unified view. Word-level highlights inside changed lines. The reason none of this has been replaced is that it works.
When you need a diff and you don't have a Git repo
Most diff tools assume you're comparing files in a Git repository. They don't help when you have two drafts of an email, two paragraphs from different versions of a brief, two snippets of code pasted from Slack messages, or two outputs from a tool that you want to verify match.
This page handles all of those. Paste the old version on the left, the new version on the right, and read the highlights. Both texts stay entirely in your browser; nothing leaves the tab.
Reading the colors
The convention is universal:
- Red, with a strikethrough vibe: content that was in the original but is gone in the updated version (a removal).
- Green: content that was added in the updated version (an insertion).
- Saffron / amber: modified lines, where the line is recognizably "the same line" but with internal edits. Word-level highlights inside show exactly which words changed.
Unchanged lines are shown without highlight on both sides. Empty placeholder rows (∅) appear when one side has nothing at that position, e.g. an added line on the right has nothing matching on the left.
Side-by-side vs unified view
The default side-by-side layout keeps the original and updated versions in two columns, so the relationship between lines is easy to see. Unified view stacks every change inline, prefixed with + for additions, - for removals, and ~ for modified pairs, the same format git diff produces in a terminal. Pick side-by-side when you want to read changes in context; pick unified when you want a compact patch-style view to scan or share.
Why word-level diffs sometimes look noisy
When you change one word in a long sentence, the word-level diff is gorgeous: exactly the changed word lights up. When you rewrite half a sentence, the algorithm tries to find the longest common subsequence at the token level and the result can look fragmented: tiny equal segments interspersed with small added/removed segments.
This is unavoidable for substantial rewrites. The signal stays correct (red shows what was, green shows what is), but trust the line as a whole over the word-level highlights when more than half the line was changed.
Ignore whitespace and ignore case
Two toggles let you tune what counts as a real change.
Ignore whitespace collapses runs of spaces and tabs, and trims leading and trailing whitespace, before comparing. Useful when only indentation or formatting changed but the actual content is identical. The original text is still shown in the diff; only the comparison treats the lines as equal.
Ignore case treats upper and lower case as equivalent. Useful for SQL keywords, environment variable names, or anywhere case is incidental. Applied to both the line-level comparison and the word-level highlights inside modified lines.
When this tool isn't the right choice
Two cases:
Very large files. The algorithm is O(n*m), fast enough for a few thousand lines per side, but quadratically slower for tens of thousands. For large diffs, use git diff, an editor's diff view, or a dedicated tool like Beyond Compare.
Diffs across many files. This page compares two pieces of text. For comparing two folders of files, two branches of a Git repository, or two database schemas, use a directory-aware diff tool.
For the in-between case, small to medium texts, two pieces, one comparison, this is the right tool.
A few high-value uses
- Drafting: paste an old version and a new version of an email or essay; see exactly which sentences moved.
- Code review on the side: paste two snippets to compare without opening an editor.
- Output verification: run the same query twice, paste both outputs, confirm they match.
- Translation review: paste original and translation side by side to spot missing paragraphs.
- Spec compliance: paste the spec and your implementation; see which clauses you addressed.
- Contract redlining: paste old and new versions of a contract to spot revisions.
The pattern is always the same: two texts, one question, what changed? This page answers it in one paste.