Text & Code Diff Viewer

What is a diff, and how are lines matched up?

A diff answers one question: what is the smallest set of edits that turns text A into text B?

The answer comes from finding the longest common subsequence — the longest sequence of lines that appears in both versions, in order, though not necessarily adjacent. Everything in that sequence is unchanged. Everything else is an insertion or a deletion. The Myers algorithm, which this page uses through the diff library, is the standard way to compute it and is what git diff uses too.

One consequence is worth knowing: a diff has no concept of "modified". A changed line is a deletion followed by an insertion. That is why a one-character typo fix shows as - and + rather than a single "edited" row.

This page reunites those pairs for display and then compares them again at word level, so you can see that only one word changed rather than being told the whole line is different.

Line, word and character granularity

The three modes answer the same question at different resolutions. The line alignment is identical in all three; only what happens inside a changed pair differs.

Take timeout = 30 becoming timeout = 300:

Word mode is the sensible default for most text. Character mode becomes noisy on prose — reordering a sentence produces a shredded highlight — but it is exactly right when you are hunting a single wrong digit in a long token.

How to compare two versions

1. Paste the original on the left, the changed version on the right Side labelling matters: - rows come from the left and + rows from the right. Swap the sides if you pasted them the wrong way round.
2. Choose the granularity Word is a good starting point. Switch to character when a change is smaller than a word, or to line when word highlighting is too busy.
3. Adjust what counts as a difference Line-ending normalisation is on by default because a CRLF versus LF mismatch otherwise reports every single line as changed. The other options are off so nothing is hidden without you asking.
4. Read the aligned result Both original and new line numbers are shown, so a row tells you where the text is in each version rather than just that it changed.
5. Export a unified patch if you need one The unified diff is the format git apply and patch accept, with three lines of context.

False differences: when text looks identical but is not

This is the single most common reason a diff is confusing. Several characters are invisible in an editor but count as changes, and this page names them explicitly rather than leaving you to guess.

The last two are the ones that waste real time, because nothing in the rendered text hints at them. When the diff says two apparently identical lines differ, a BOM or a non-breaking space is the usual explanation, and switching to character mode makes the position obvious.

Examples of what the output looks like

A configuration change, in word mode:

 1  1   host = localhost      →  host = api.internal
 2  2   port = 8080           →  port = 8443
 3  3   timeout = 30              (unchanged)
 4  4   retries = 3           →  retries = 5
    5  + tls = true

Line 5 exists only on the right, so it has no left-hand number. That asymmetry is what makes numbered diffs useful for review: you can reference "line 4 in the old version" and "line 4 in the new version" without ambiguity.

The same change as a unified patch:

@@ -1,4 +1,5 @@
-host = localhost
-port = 8080
+host = api.internal
+port = 8443
 timeout = 30
-retries = 3
+retries = 5
+tls = true

The @@ -1,4 +1,5 @@ header means "4 lines starting at line 1 in the original become 5 lines starting at line 1 in the new version".

What this tool does not do

• No merging. This is a comparison view, not a three-way merge. There is no common ancestor, no conflict resolution and no way to apply changes from one side to the other. Git, or your editor's merge tool, is the right place for that.
• No move detection. A block moved from the top of a file to the bottom is reported as a deletion plus an addition, not as a move. That is standard diff behaviour, and it is why reordered lists look like large changes.
• No syntax awareness. Comparison is on text, not on parsed structure. Reformatting JSON without changing any value still produces a large diff. For that specific case, comparing parsed structures with the JSON Diff tool gives a much smaller and more meaningful result.
• No files. Text is pasted rather than uploaded. Open the files and copy the contents across.
• No binary comparison. Line-based diffing is meaningless for images or compiled output.

Practical limits: the aligned view renders the first 2,000 rows. The unified patch always covers the full comparison, so nothing is lost from the exportable output.

Use cases

• Reviewing a config change before deploying. Comparing the current and proposed versions of a config file catches an unintended edit that a code review might skim past.
• Checking what an AI or a formatter changed. Paste before and after to see the actual edits rather than trusting a summary.
• Comparing API responses across environments. Staging and production payloads side by side reveal which fields differ.
• Proofreading two drafts. Word mode reads naturally on prose and shows exactly which phrases were rewritten.
• Diagnosing "it works on my machine". Compare two dependency lock files, two environment variable dumps, or two versions of the same script.
• Verifying a manual data migration. Compare the exported source and the transformed output row by row.
• Finding an invisible character. When a string comparison fails in code but the values look the same, character mode plus the invisible-difference notes usually pinpoint it in seconds.

Privacy

Both texts stay in the page. Comparison runs in your browser and nothing is uploaded or written to storage, which matters when you are diffing production configuration or unpublished content.