Text diffs: unified view and workflow

Published: 2026-09-05

How line, word, and character diffs work, when to use side-by-side vs inline (unified) layout, and a practical local workflow for reviewing text changes without uploading paste.

A text diff shows what changed between an original string and a modified string: additions, deletions, and (depending on the algorithm) replacements. Git, code review UIs, and patch files all speak this language. The same idea is useful outside source control—comparing config drafts, API payloads, docs rewrites, or two email templates—whenever you need to see the delta instead of scanning two full copies by eye.

Online “paste and compare” sites often upload both sides to a server. For secrets, customer data, or internal hostnames, prefer a local diff that never leaves the tab. LocalTools’ Diff Checker runs the comparison in your browser with the same privacy model as other local-only developer tools.

What a diff actually computes

Most browser and library diffs (including the common diff package) split text into tokens, then find a longest common subsequence (or similar alignment). Unmatched tokens on the left are deletions; unmatched tokens on the right are additions. Identical tokens stay unmarked.

The token size is the granularity you choose:

Level	Tokens are…	Best when…	Noise risk
Line	Whole lines (split on `\n`)	Code, logs, configs, prose paragraphs	Misses small edits inside a long line
Word	Whitespace-separated words	Copy edits, docs, JSON keys/values on one line	Punctuation glued to words can look “bigger” than it is
Character	Individual characters	Typos, IDs, minified one-liners	Can paint almost every character if the texts diverge a lot

Start at line for structured text. Drop to word when a single line changed but you need to see which phrases moved. Use character sparingly—for short strings or when word boundaries do not exist (hex, base64, compacted JSON).

Side-by-side vs inline (unified-style)

Review UIs usually offer two layouts. Names vary; the ideas do not.

Side-by-side

Original on the left, modified on the right, often with synced scroll. You see both full contexts at once. Ideal when:

The files are long and you need surrounding lines on both sides.
You are checking that an edit did not accidentally change neighboring sections.
You want to “read left, then right” like a merge tool.

Inline / unified-style

Changes appear in one stream: deleted spans in red, added spans in green, often interleaved in reading order. Classic unified diff (diff -u / Git’s default patch format) is the file-based cousin of this idea—hunks with - / + lines and a little context. Inline views are ideal when:

The delta is small and you want one scrollable story.
You are pasting a short before/after (error messages, one JSON object, a paragraph).
Screen width is limited (phone or narrow pane).

Neither layout is “more correct.” Pick the one that matches how you read: compare columns vs follow the narrative of the change.

Ignore whitespace (and when not to)

Whitespace-only churn is common after formatters, copy-paste from docs, or CRLF vs LF line endings. An ignore whitespace option collapses or trims space/newline differences so the highlight focuses on meaningful tokens.

Turn it on when you care about semantic content (wording, keys, values) and formatting noise is drowning the signal. Leave it off when whitespace is the bug—indentation in Python/YAML, trailing spaces in Makefile rules, or accidental blank lines in a signed payload.

If one side is messy and you want a clean baseline first, normalize elsewhere (for example a whitespace normalizer when that tool fits), then diff. Diffing and normalizing solve different jobs: one shows change; the other rewrites it.

A practical review workflow

Paste original and modified into two panes (or swap sides if you pasted them backwards).
Choose line diff + side-by-side for the first pass on anything multi-line.
Enable ignore whitespace if the first result is mostly green/red noise on spaces.
Zoom in with word or character granularity on the hunks that still look wrong.
Switch to inline when you need a compact reading of a small edit set.
Copy the diff text into a ticket or chat only after scrubbing secrets—treat the export like any other shareable artifact (code screenshots have the same hygiene problem).

For bulk literal or regex edits before you compare versions, batch find & replace can produce the “modified” side; the diff then verifies you hit every intended occurrence and nothing else.

Unified patches vs interactive viewers

A unified patch is a portable text format (@@ hunks, - / + lines) you can email, attach to a PR, or apply with git apply. An interactive viewer (browser side-by-side/inline) is better for exploration: swap sides, change granularity, ignore whitespace, and re-compare without writing a file.

Use patches when you need a durable artifact for review systems. Use a local viewer when you are still deciding what the change is—especially when the text should not be uploaded.

Common pitfalls

Wrong baseline — Diffing “new vs old” when you meant the reverse flips adds and deletes. Use swap sides instead of re-pasting.
Mixed line endings — One side \n, the other \r\n, can mark every line as changed at line granularity unless you normalize or ignore whitespace carefully.
Minified vs pretty — Pretty-printing one JSON blob and not the other produces a useless line diff. Format both the same way first (for JSON, see formatting and minifying safely).
Huge pastes — Very large texts can feel slow in the browser; crop to the relevant region when you already know where the change lives.
Assuming “no changes” means identical bytes — With ignore-whitespace on, two strings can report no changes while still differing in spaces.

Try it locally

Open the Diff Checker:

Paste Original and Modified text.
Set Diff level to character, word, or line, and Layout to side-by-side or inline.
Optionally turn on Ignore whitespace, then Compare Now.
Use Swap sides, Copy diff text, or clear the result as needed.

Everything runs in your browser; the two texts are not sent to LocalTools for comparison.