Diff Checker

A diff (short for difference) is a comparison between two pieces of text that shows exactly what was added removed or changed. The concept originated with the Unix diff utility created in the early 1970s at Bell Labs and it has become fundamental to software development content editing and version control. In its simplest form a diff highlights deletions (lines present in the original but missing from the modified version) and additions (lines present in the modified version but missing from the original). More advanced diff tools also detect moved lines changed words within a line and refactored content that has been reorganized but not fundamentally altered. Diffs are the backbone of every version control system. When you make a commit in Git you are saving a diff — the set of changes between the previous version and the current version of your files. Pull requests on GitHub display diffs so that reviewers can see exactly what code changed. Configuration management tools use diffs to show what will change before applying updates. Beyond code diffs are useful for comparing contracts detecting changes in website content verifying that data migrations preserved information correctly and auditing configuration files for unintended modifications.

Text comparison algorithms work by finding the longest common subsequence (LCS) between two texts — the longest sequence of elements that appears in both texts in the same order. Everything not part of this common subsequence is either an addition or a deletion. The classic algorithm for this published by Eugene Myers in 1986 is what most diff tools use today. The comparison can operate at different granularity levels. Line-level diff compares entire lines and marks whole lines as added removed or unchanged. This is the default mode for code review and the output format used by Git. Word-level diff breaks lines into individual words and highlights exactly which words changed — useful for comparing prose and documents where changes are often small edits within paragraphs. Character-level diff provides the finest granularity highlighting individual character changes. This is particularly useful for spotting typos detecting single-character differences in configuration values or comparing encoded strings where even one character difference matters. Some diff tools also support semantic diff which understands the structure of the content being compared. A semantic diff for code understands that renaming a variable is a single logical change even though it affects many lines. For HTML or XML a structural diff can identify that elements were moved or reordered rather than deleted and re-added.

Myers (1986) is the classic: it finds the shortest edit script (SES) — minimum insertions + deletions to go from A to B. Fast but sometimes produces confusing diffs because it greedily matches any common line. Patience diff (Bram Cohen 2008) identifies unique anchor lines first and diffs between anchors — producing more human-readable results especially for refactors with reordered code. Git uses Myers by default; add --patience to switch. For large refactors histogram diff (an optimization of patience) is now git's recommended default via --histogram.

Unified diff is the @@ -N M +N' M' @@ format you see in git diff and patch files. Headers indicate line ranges in both files; - prefixes removed lines + prefixes added lines unprefixed lines are context (3 lines of context by default). It's a standard (RFC-ish — de facto since patch(1) adopted it). Alternatives: context diff (-C3 older) side-by-side (-y Git's colored word-diff (--word-diff. Unified is the universal interchange format — copy-paste into a file and patch < file.diff applies it.

Most useful: --stat (summary with file change counts) --numstat (machine-readable) --word-diff (highlights changed words inline — great for prose) --ignore-all-space / -w (ignore whitespace) --color-moved=zebra (highlights moved code blocks not just deleted+added) --patience or --histogram (cleaner diffs for refactors) and --unified=0 (no context lines just the change hunks). For reviewing PRs -M -C flag pair detects renames and copies automatically.

Inline (unified single column with +/- lines) is better for SMALL diffs and terminal review — fits in 80 cols easy to scan works in email/markdown. Side-by-side is better for LARGER diffs especially refactors where you want to see the before and after structure at a glance. GitHub GitLab and most IDEs offer a toggle. Reviewer-habit research suggests side-by-side increases comprehension for diffs >50 lines but slows small reviews. Default to inline; switch for complex changes.

For text files algorithmic diff scales to ~100k lines per side comfortably; beyond that specialized tools like diff --minimal or chunked line-based algorithms (hash-then-compare) are needed. For binary files — images PDFs executables — standard diff isn't useful; it reports binary files differ and stops. Tools: imagemagick compare for images pdf-diff for PDFs radare2/Ghidra for binaries. For Office docs LibreOffice has a built-in visual diff; Word's track-changes is still the native workflow.