Text Diff

A text diff takes two snapshots of the same content — an "old" version and a "new" version — and renders the differences between them so a human can verify what changed. It does not understand the meaning of the text; it operates strictly on lines (or characters), marking which ones are present in one side but not the other. That neutrality is its biggest strength: anything that can be written down as text can be diffed the same way, whether it is documentation, configuration, prompts for an LLM, copy for a marketing page, or a transcript of a chat.

Why eyeballing two versions side by side is not enough

Manual comparison breaks down once the documents are more than a few dozen lines, or once the edits include reordered sections, deleted blocks, or whitespace cleanup. The eye is good at noticing wording differences in adjacent lines and very bad at noticing a missing line in the middle of a long block. A diff tool levels the field by marking every line that is not present on both sides, so you stop trusting your peripheral attention and start trusting a checklist.

How a line-based diff decides what "changed" means

A line-based diff treats each line as an atomic unit. It looks for the longest sequence of lines that appears in both sides in the same relative order, calls that the unchanged backbone, and reports everything else as additions or removals. That is why two visually similar files can produce very different diffs: small changes in line structure can shift what the algorithm treats as the common backbone.

• A line that exists on both sides at corresponding positions is unchanged.
• A line that exists only on the right (new) side is an addition.
• A line that exists only on the left (old) side is a removal.
• A "modified" line is conceptually one removal plus one addition placed next to each other — the algorithm does not have a special "change" verb of its own.
• Reordering one block to another position usually shows up as a delete in one place plus an add in another — not as a move.

Rule of thumb: a diff tells you what the algorithm believes changed line-by-line. It cannot tell you whether the change is meaningful — that is still your job.

How to use this tool

1. Prepare representative two versions of plain text, config fragments, notes, or generated output in Text Diff instead of starting with the largest or most sensitive real input.
2. Run the workflow, generate a visible diff showing added and removed lines, and review line breaks, whitespace-only changes, reordered sections, and whether the diff should be reviewed as text rather than structured data before deciding the result is ready.
3. Only copy or download the result after it fits copy review, release-note checks, config comparisons, prompt revisions, and support-ticket evidence and no longer conflicts with this constraint: For structured formats such as JSON, use the matching structured diff tool when key-level changes matter.

Text Diff example

This Text Diff example uses representative two versions of plain text, config fragments, notes, or generated output and shows the resulting a visible diff showing added and removed lines, so you can confirm line breaks, whitespace-only changes, reordered sections, and whether the diff should be reviewed as text rather than structured data before applying the same settings to real input.

Sample input

Before: timeout=30
After: timeout=45

Expected output

- timeout=30
+ timeout=45

A copy edit, shown as a line-level diff

# old
Welcome to the launch.
Doors open at 6 PM.
Please bring a printed invitation.
Refreshments will be served.

# new
Welcome to the product launch.
Doors open at 6:30 PM.
Refreshments and drinks will be served.

# diff
- Welcome to the launch.
+ Welcome to the product launch.
- Doors open at 6 PM.
+ Doors open at 6:30 PM.
- Please bring a printed invitation.
- Refreshments will be served.
+ Refreshments and drinks will be served.

Notice that "removed: please bring a printed invitation" is an isolated delete — there is no matching addition. The diff highlights it precisely because that single line is easy to miss visually.

Where a text diff is the right tool

Text diff is at its best when the content does not have to follow a strict structure but still needs careful review. The list below is where a quick paste-and-compare almost always saves time.

• Reviewing a copy edit on a landing page, email, or press release where every word matters.
• Confirming a colleague's edits in a config file or environment template before merging.
• Comparing two prompts (or two prompt revisions) for an LLM to understand why outputs differ.
• Verifying that a search-and-replace really only touched the intended occurrences, not their neighbours.
• Auditing what changed between two versions of a transcript, meeting note, or audit log.

Pitfalls that make a diff misleading

A diff is only as useful as the input you give it. The most common cause of a confusing diff is not a bug in the algorithm but a mismatch between what you wanted to compare and what the tool actually compared.

• Trailing whitespace and invisible characters: lines that look identical can differ by a single space or a BOM and show up as changed.
• Different line endings: CRLF (Windows) vs LF (Unix) will mark every line as changed if the tool does not normalise them.
• Reflowed paragraphs: when an editor wraps long lines into shorter ones, a line diff explodes even though the wording is identical.
• Encoding differences: UTF-8 vs UTF-8 with BOM, or different normalisation forms for accented characters, can cause silent mismatches.
• Comparing a fragment against a full document: if you accidentally include or exclude a header, the entire backbone shifts and the diff becomes unreadable.

Text diff vs other comparison strategies

Practical Notes

• Review line breaks, whitespace-only changes, reordered sections, and whether the diff should be reviewed as text rather than structured data before you reuse the a visible diff showing added and removed lines.
• For structured formats such as JSON, use the matching structured diff tool when key-level changes matter.
• Keep the original two versions of plain text, config fragments, notes, or generated output available when the result affects production work or customer-visible content.

Text Diff reference

Text Diff reference content should stay anchored to two versions of plain text, config fragments, notes, or generated output, the generated a visible diff showing added and removed lines, and the checks needed before copy review, release-note checks, config comparisons, prompt revisions, and support-ticket evidence.

• Input focus: two versions of plain text, config fragments, notes, or generated output.
• Output focus: a visible diff showing added and removed lines.
• Review focus: line breaks, whitespace-only changes, reordered sections, and whether the diff should be reviewed as text rather than structured data.

References

• Unicode Standard Annex #15: Unicode Normalization Forms
• MDN: String