Patch / Diff Inspector

How to use

1. Paste a unified diff into the box, or drop a .patch or .diff file onto it.
2. Read the totals to see the size of the change: files touched, insertions, deletions and hunk count.
3. Scan the table for the files you care about; renames show the old path alongside the new one.
4. Check anything highlighted in amber before running git apply — those are the reasons it would fail.
5. For a patch from an email, compare the hunk warning against `git apply --check`, which reports the same corruption with less detail.

Frequently asked questions

What does `corrupt patch at line N` actually mean?

It means the hunk body did not contain the number of lines its header declared. A header like @@ -1,4 +1,5 @@ promises four lines on the old side (context plus removals) and five on the new side (context plus additions). git counts as it reads and stops the moment the arithmetic breaks, reporting the line it reached rather than the header that was wrong. Almost always the cause is transport: a mail client wrapped a long line, or stripped the single leading space that marks a context line, so one side comes up short. This tool reports the hunk, the counts it promised and the counts it delivered, which is normally enough to fix by hand.

Why do blank context lines break patches so often?

Because a context line is marked by a single leading space, and an unchanged blank line is therefore a line consisting of exactly one space. That is invisible, and a great many tools trim it — editors that strip trailing whitespace on save, mail clients, chat apps, copy-paste through a terminal. Once the space is gone the line reads as an empty line rather than as context, and the hunk is one line short on both sides. It is the single most common way a patch that looked fine on screen fails to apply.

Does this tool apply the patch or check it against my files?

No, and it cannot. It reads the patch itself — the arithmetic inside the diff — with no access to the files it targets. That is enough to catch a corrupt or mangled patch, which is a property of the patch alone. It cannot tell you whether the context lines match your working tree, so a patch this tool calls well-formed can still be rejected with `does not apply` if the file has moved on. For that check you need the files, and `git apply --check` is the command.

Can it read a plain `diff -u` output as well as a git patch?

Yes. A git patch adds the `diff --git` line, the index line, rename and mode metadata and — from git format-patch — a mail header, all of which are read when present. A plain unified diff from diff -u has none of that: it opens straight into a `--- ` / `+++ ` header pair, and is handled the same way. Renames and mode changes simply cannot be detected in the plain form, because the format has no way to express them.

Why does the line count here differ from what GitHub shows?

GitHub's file view counts the same lines, but its summary sometimes differs because it hides generated files, collapses large diffs, and excludes binary files from the totals. This tool counts every hunk in the patch you gave it, which is the same number `git apply --numstat` reports. If the totals differ, check whether the patch you have is the whole change — a .patch URL for one commit will not match a pull request's cumulative diff.

Is my patch uploaded anywhere?

No. The text is parsed by JavaScript on this page and never sent anywhere; the same is true of a dropped file, which is read with the browser's own file API. You can confirm it by loading the page, disconnecting from the network and pasting a diff — it still works. Worth knowing, since a patch is often the most sensitive thing in a review: it contains unreleased code in full.

Related tools