Git Diff & Patch Viewer
Parse and render a unified diff or .patch file with per-file stats and colour-coded hunks.
What is Diff Viewer?
A unified diff viewer. It reads the raw patch rather than the rendered page, so it works on git diff output, a commit from git show, a .patch file and several commits pasted together.
How it works
The text is scanned for `diff --git` headers and the metadata that follows them — index lines, modes, rename/copy lines, binary stubs — then hunks are parsed line by line with old and new line counters maintained from the @@ ranges. Each file gets a status badge, insertion and deletion counts, and a summary line, while malformed regions are reported as parser notes so an incomplete paste is obvious.
- Paste or fill in the input. Drop in a commit message, a diff, a package.json, a path list or a set of options. The tool reads it locally — nothing is uploaded and no repository is contacted.
- Adjust the rules to match your project. Every linter here takes its convention from a setting you can change: allowed commit types, header length, target branch length, known branch names. Set them once to what your team actually uses.
- Copy the result. Generated files copy straight to the clipboard or download as a real file with the right name (.gitignore, CODEOWNERS, LICENSE, COMMIT_EDITMSG), and Reset returns every field to its default.
Examples
A commit message that fails CI
"Updated(auth): Fixed the expired-token redirect." is rejected by release automation and reported here with the exact reasons: unknown type, capitalised description, past tense and a trailing period.
A .gitignore that only half works
The Checker shows which rule decides a path — and why `!keep.txt` inside an ignored directory never fires, the mistake that sends people to Stack Overflow.
A dependency bump nobody reviewed
The package.json Diff separates added, removed and changed entries per section, so a caret bump of a runtime dependency does not hide inside a lockfile-sized pull request.
A diff pasted from a code review comment
The Diff Viewer understands several `diff --git` blocks, mode-only changes, renames and binary stubs, and calls out a pasted `--stat` summary instead of rendering an empty box.
Common mistakes
Committing a .gitignore without checking it
Rules look right and behave differently: a pattern containing a slash is anchored to the root, a trailing slash means directories only, and a file inside an ignored directory cannot be re-included. Check the paths that matter before you commit the file.
Rewriting published history
A clean commit history is worth having, but amend, rebase and filter-repo change commit hashes. Only rewrite commits that nobody has pulled; after a rewrite, push with --force-with-lease rather than --force.
Treating a generated file as if it were reviewed
These tools produce a starting point, not a decision. Check the licence text against the canonical source, read the security policy before publishing it, and make sure a CODEOWNERS team actually exists — GitHub silently ignores rules whose owner has no write access.
Putting slow checks in a pre-commit hook
A hook that takes 30 seconds gets bypassed with --no-verify within a week, and then it protects nothing. Keep pre-commit to formatting and linting, move type checks and tests to pre-push or CI.
Frequently asked questions
Why does the viewer say my paste is a diff stat?
Because a `--stat` summary (`src/app.ts | 4 ++--`) contains no hunks. Run git diff without --stat, or git show for a single commit, and paste that.
Can it show word-level changes?
No. A unified diff does not carry word-level information unless it was generated with --word-diff, which produces a different format entirely. This viewer renders line-level changes and labels each line with its source line number.
What does the mode-only entry mean?
That only the file's permission bits changed — usually `git update-index --chmod=+x`, which is how a script becomes executable in the repository. There is no content diff to show.