Diff Checker — Compare Code, Config Files & Text

Paste the old config on the left and the new one on the right, then use line mode to see which settings were added or removed and word or character mode to spot a changed value inside a line. For structured formats, normalize both sides first so formatting noise doesn't hide the real change: run JSON through a formatter with the same indentation, and for YAML convert both to JSON. For .env and INI files, sorting the lines (sort file.env) before comparing makes reordered keys disappear from the diff.

A text diff compares characters, so {"a":1,"b":2} and {"b":2,"a":1} show as different even though they are the same JSON object. Sort the keys on both sides first — jq -S . old.json > old.sorted.json does it on the command line — then paste the sorted versions here. Arrays are ordered in JSON, so a reordered array is a real difference.

With this diff checker, yes: both texts are compared by JavaScript in your browser and nothing is uploaded or saved on a server. That matters because configs are exactly where database passwords, API keys and connection strings live. Online tools that store pasted content have leaked exactly this kind of data — see the JSONFormatter and CodeBeautify leak. If you use any other diff tool, check DevTools → Network while you paste.

Use diff -u old.txt new.txt for a unified diff, or git diff --no-index old.txt new.txt to get git's coloured output for any two files, even outside a repository. Add --word-diff to git diff for word-level changes, and -w to ignore whitespace. For directories, diff -ru dirA dirB compares recursively.

Most diff tools implement the Myers diff algorithm (1986), which finds the shortest edit script — the minimum set of insertions and deletions to transform one text into another. This is equivalent to finding the Longest Common Subsequence (LCS). It is the default algorithm used by GNU diff and git diff. The choice of algorithm matters because a poor implementation can produce technically correct but confusing results where logically related changes appear split across many unrelated hunks.

A line diff compares documents line by line and marks entire lines as added or removed — the default mode and most useful for code. A word diff identifies which specific words within a changed line were altered (git diff --word-diff uses this). A character diff compares at the individual character level, most useful for catching typos, small config value changes, or comparing encoded strings. Many tools show a line diff with intra-line character highlighting as a hybrid approach.

In unified diff format (produced by diff -u or git diff), lines prefixed with - are removed and lines prefixed with + are added. The @@ header shows the affected line ranges: @@ -10,7 +10,6 @@ means the original file at line 10 had 7 lines, the new file at line 10 has 6 lines. Unchanged context lines have no prefix. This format is standard for patch files and code review. Context diff (diff -c) is an older alternative that shows the two files in separate sections.

By default, whitespace changes are treated as real differences. In git diff you can use --ignore-space-change (-b) to ignore changes in the amount of whitespace, or --ignore-all-space (-w) to ignore all whitespace entirely. This is essential when comparing code that was reformatted or had tabs converted to spaces. Note: ignoring whitespace can mask significant indentation changes in Python or YAML files where indentation is structurally meaningful.

Several invisible factors cause this: line endings (\r\n on Windows vs \n on Unix), a BOM (Byte Order Mark \xEF\xBB\xBF) at the start of a UTF-8 file, trailing spaces or tabs at the end of lines, and encoding differences (UTF-8 vs UTF-16 vs Latin-1). A diff showing differences between files that 'look the same' is almost always one of these. On macOS/Linux, cat -A reveals hidden characters; a hex viewer is the definitive diagnostic.