Guide · Updated 2026-07-23
How to Read a Text Diff (Unified and Side-by-Side)
Understand added and removed lines, hunk headers, and context lines so code and config diffs become useful instead of noisy.
What a diff is showing
A text diff compares two versions of a file and highlights what changed. Additions and deletions are relative: left (or 'before') versus right (or 'after'). Nothing in a diff executes — it is only a map of textual differences.
Unified diffs show both sides in one column with `-` for removed lines and `+` for added lines. Side-by-side views place old and new next to each other for wide files with small edits.
Unchanged context lines surround edits so you know where in the file the change landed. Context is not 'partially changed' — it anchors location.
Reading hunk headers
Unified diff hunks start with `@@ -oldStart,oldCount +newStart,newCount @@`. The numbers are line positions in the before and after files, not line numbers inside the hunk display itself.
A hunk with `-10,5 +10,6` might mean five lines starting at line 10 were replaced by six lines starting at line 10 — one line was inserted net. Off-by-one confusion is common; trust the highlighted `-`/`+` lines over mental arithmetic.
Multiple hunks mean multiple separated edits. Skipping the middle of a large diff misses secondary changes as often as the main edit.
Noise vs signal
Whitespace-only changes show as entire lines removed and re-added. Ignore them in semantic review or enable whitespace-insensitive diff if the tool supports it.
JSON and XML diffs look noisy when key order changes but values do not. Pretty-print both sides before diffing to separate formatting churn from data changes.
Generated files (lockfiles, build output) produce huge diffs for small dependency bumps. Focus review on source files; skim generated deltas for unexpected package names.
Using diffs in daily work
Before merging config, diff production against staging. Before closing a support ticket, diff customer JSON against your golden example.
When a regex or parser change breaks tests, diff expected versus actual outputs. The first differing line often pinpoints an off-by-one capture group.
Save diff outputs in tickets with redaction. They communicate scope better than prose ('changed a few lines') and prevent accidental re-edits of the wrong section.
Ready to try it? Open Diff Checker