Skip to content
tooljo Diff tools in: Dev tools
100% in your browser. Nothing you paste is uploaded — all processing runs locally. Read more →

Why your diff shows the wrong changes — five sources of noise and how to silence them

5 min read #diff #git #code review

You changed one function. The diff shows 200 lines changed. Half the file is “different” but visually identical. Five common causes — each easy to silence once you know the trick.

1. Whitespace-only changes

Indentation moved from tabs to spaces (or vice-versa). A code formatter ran. Trailing spaces got stripped. The actual logic is unchanged but every modified line shows in the diff.

Fix in Git:

git diff -w           # ignore all whitespace
git diff --ignore-all-space
git diff --ignore-space-change   # only collapse runs of whitespace
git diff --ignore-blank-lines

Fix in this tool: tick “Ignore whitespace” — same effect.

Better long-term fix: agree on a formatter (Prettier, Black, gofmt, rustfmt) and run it on commit. The “format-on-save” debate has a clear answer: format-on-save, with the formatter pinned in the repo.

2. CRLF vs LF line endings

Windows writes \r\n, Unix writes \n. Cross-platform repos accumulate CRLF/LF mismatches that break diffs in confusing ways: the line text is identical, but the trailing \r makes them unequal.

Symptoms:

Fix in Git:

# Configure Git to normalise on commit:
git config --global core.autocrlf input    # Mac/Linux
git config --global core.autocrlf true     # Windows

# Add a .gitattributes file to lock it in:
* text=auto
*.sh text eol=lf
*.bat text eol=crlf

Fix in this tool: tick “Ignore whitespace” — covers line-ending mismatches.

3. Trailing newline at end of file

POSIX says a text file ends with \n. Some editors don’t add one. Most diff tools render the absence as \ No newline at end of file.

When you change a file’s last line and add the missing trailing newline (or remove an existing one), the diff shows the last line as changed even though only the trailing \n differs.

Fix: configure your editor to add a final newline on save (most modern editors have this option; in VS Code: "files.insertFinalNewline": true). Once standardised, this issue disappears.

Fix in this tool: same — “Ignore whitespace” treats the trailing \n as whitespace.

4. Generated files / lockfiles in the diff

Lockfiles (package-lock.json, Cargo.lock, Pipfile.lock), build artifacts, generated TypeScript types — all of these should be in version control but they generate noise in code review.

Fix in Git: mark them as linguist-generated in .gitattributes:

package-lock.json linguist-generated=true
*.lock linguist-generated=true
generated/* linguist-generated=true

GitHub will collapse these in PR diffs. They’re still committed, but the reviewer sees them only when they ask.

Fix in code review: discipline. Commit lockfile updates separately from feature changes. A PR titled “bump dependencies” is reviewable; the same diff mixed into “add new feature” is not.

5. UTF-8 BOM or encoding mismatch

A Windows editor saved a file with a UTF-8 BOM (\xEF\xBB\xBF at the start). A Mac editor saved without. The bytes are different; the content is identical. Diffs show “the entire file changed.”

Less common: someone accidentally saved a file as UTF-16, or as ISO-8859-1 instead of UTF-8. Now the file is technically a different sequence of bytes for any character outside ASCII.

Symptoms:

Fix: normalise to UTF-8 without BOM before committing. Most editors have this option (VS Code: bottom-right of the status bar, click the encoding label).

A bonus issue: reordered imports

Auto-import tools (TypeScript, Python isort, Java IDE auto-import) often reorder imports alphabetically. Two devs working on the same file end up with different import orders even when the actual logic is identical.

Fix: commit isort / Prettier import-sorting / similar to the repo as a pre-commit hook. The first commit is noisy (sorts everything); all subsequent commits are clean.

Detecting which cause you’re hitting

A quick triage:

  1. Same content visible, but lines marked changed? → whitespace, CRLF, or trailing newline. Try git diff -w first; it kills 80% of these.
  2. Whole file shows changed including unmodified text? → encoding or BOM. Check file -bi.
  3. Imports / lockfile / generated files dominating the diff? → commit-time discipline + .gitattributes.
  4. Looks fine in a single file but messy across many? → formatter churn (someone ran a formatter on changed-but-also-touched files).

The bigger lesson

Most “diff noise” is recoverable when you set up the toolchain to normalise before the diff sees the input:

The diff tool on this site has the post-hoc switches (ignore whitespace, ignore case) but they’re a band-aid. The real fix is upstream — agree on the format, run it automatically, and your future diffs only show real changes.

Try the tool

diff.tooljo.com — paste two texts, see the diff side-by-side or unified. Ignore-whitespace toggle handles cases 1, 2, and 3 above.