Complete Guide to Text Diff and Code Comparison
What is a diff and why it matters
A 'diff' (short for difference) is a precise description of how one text transforms into another. Originally a Unix command-line tool, diffing has become essential to software development: Git uses it to show what changed between commits, code review tools use it to display pull request changes, and editors use it to show unsaved changes. Understanding how to read and interpret a diff is one of the most fundamental skills for any developer or technical writer.
How the LCS algorithm works
Most diff tools — including this one and Git — are based on the Longest Common Subsequence (LCS) algorithm. The algorithm finds the longest sequence of lines that appear in the same order in both texts without being modified. Everything not in that common sequence is either an addition (present in the new text but not the original) or a deletion (present in the original but not the new text). The Myers diff algorithm, used in Git, finds the LCS with a clever optimization that favors shorter edit scripts, producing diffs that are easier for humans to read.
Unified diff vs side-by-side diff
There are two common ways to display a diff. A unified diff (what you see in `git diff` output) merges both files into a single column, with lines prefixed by '+' for additions and '-' for deletions. A side-by-side diff (what this tool shows) displays the original on the left and the new version on the right, with changes highlighted inline. Side-by-side is generally easier to read for understanding context, while unified diff is more compact and easier to share or apply as a patch.
Reading a Git diff
A Git unified diff starts with a header showing which files are compared. Then come one or more 'hunks' — each hunk starts with `@@ -a,b +c,d @@` meaning 'starting at line a in the original (b lines shown) and line c in the new version (d lines shown)'. Lines beginning with `-` were in the original and have been removed. Lines beginning with `+` are new additions. Lines with no prefix are context — they appear in both versions and help you understand the location of the change. Knowing how to read this format is essential for reviewing pull requests and resolving merge conflicts.
Common use cases for text comparison
Configuration management is one of the most critical use cases: comparing a production config file against staging helps catch environment-specific settings that could cause bugs. Document workflows benefit from diffing when multiple people edit a shared document and you need to reconcile versions. API debugging uses diffs to compare responses from two environments — even a single field difference in a large JSON response is immediately visible. Security audits compare configuration files before and after deployments to verify only intended changes were made.
Spotting invisible differences
Some of the most frustrating bugs come from differences you can't see with the naked eye: trailing spaces at the end of lines, tabs vs spaces for indentation, Windows CRLF (\r\n) line endings vs Unix LF (\n), or Unicode characters that look identical but have different code points (for example, a regular hyphen vs an em dash, or ASCII 'a' vs a lookalike Cyrillic character). A diff checker makes these visible because even a single invisible character difference will highlight the entire section as changed. If two strings look the same but compare as different, always check the diff first.
Best practices for reviewing code changes
When reviewing a pull request or change, start with the summary — what files changed, how many lines were added and removed — before diving into individual hunks. Read each hunk in context: don't just look at the red and green lines, read the surrounding context lines too. Look for logical errors, not just syntax; the diff shows what changed but you need to reason about whether the change is correct. For large pull requests, review file by file and write down your questions before commenting so you can group related feedback. Always look at test files alongside implementation files — a change without a test update warrants a question.