Skip to content
Privacy

Everything runs in your browser. We never see your code. How we prove it →

Unified Diff & Patch Generator Online

Turn a before and an after into a unified diff you can hand to git apply — assembled here, in the page, never uploaded.

Original
Changed

How unified diff generation works

A unified diff is a short, exacting document. It opens with two header lines, conventionally `--- a/path` and `+++ b/path`, then carries one or more hunks. Each hunk begins with a marker of the form `@@ -12,7 +14,9 @@`: the starting line and run length in the original, then the starting line and run length in the result. Inside the hunk, a leading space marks a context line that must already be present in the target, a minus marks a removal, a plus an addition. This page builds that structure from your two panes with three lines of context around every change, merges hunks whose context windows overlap, and flags a missing final newline with the standard `\ No newline at end of file` marker, because that byte is a real difference.

Whether the result applies cleanly elsewhere comes down almost entirely to those context lines: `git apply` matches them literally and refuses the whole patch if the target file has drifted by a single character inside the window, rather than guessing. More context makes a patch more precise and more brittle; less makes it travel further and land in the wrong place more often. Header paths set the strip level too — git expects the `a/` and `b/` prefixes it removes with `-p1`, while `patch -p0` wants paths exactly as written — so both fields stay editable before download. To read a change rather than ship it, Code Diff shows the same comparison in colour with unchanged regions folded.

Proprietary code stays on your disk

A patch is a distilled copy of exactly the part of a codebase someone cared enough to change, which is why running proprietary source through an online generator breaks policy at most employers and every consultancy. Assembly happens inside the page: the unified diff is built by JavaScript in your tab, and the download writes a file from memory straight to your disk with no round trip through anybody's infrastructure. Open your browser's network tab while you use this tool — you'll see no request carries your content. The steps for confirming that take about a minute and need no special tooling.

Reasons to generate a patch by hand

  • A contributor to a project that still takes patches by email produces a .patch from an edited file for the mailing list, without initialising a throwaway repository purely to run git diff against it.
  • An engineer locked inside an air-gapped build host carries a two-line fix out as text because the machine has no remote configured and no credentials that could push anything anywhere.
  • A maintainer packaging a downstream fix writes a patch against a vendored library with the file headers set to the paths the build recipe already expects, so the packaging step applies it untouched.
  • A technical writer documenting an upgrade converts the before and after of a config file into the precise hunk that goes into the migration guide, letting readers apply it instead of retyping and mistyping it.
  • A support engineer shipping a customer hotfix sends an enterprise client a small, reviewable patch against the exact release they are pinned to, so their own security team can read every changed line before it touches production.

Frequently asked questions

How many context lines should I choose?

Three is the default because that is what git itself emits, and reviewers read it fluently. Drop to one or zero when the target file is actively changing and you want the patch to survive; raise it to five or more when a repeated block appears many times in the file and you need the hunk anchored unambiguously to the right occurrence.

Why does git apply reject the patch I generated?

Usually the context no longer matches the target byte for byte — a reformat, a rename, or CRLF endings meeting LF ones. Check the strip level first (`git apply -p0` when there are no a/ b/ prefixes), then try `git apply --3way`, which falls back to a merge. Whitespace-only failures often clear with `--ignore-whitespace`.

What size inputs can it handle?

Generation stays live up to 1 MB combined, then switches to an explicit Compare button; about 10 MB per side is comfortable and 50 MB is the ceiling. The patch itself is normally a fraction of that, since only changed regions plus their context are written out — a one-line fix in a large file produces a few lines of output.

Does my source get uploaded to produce the .patch?

Never. Both inputs and the generated output exist only in your tab, and the download is a local blob rather than a file fetched from a server. That is what makes this usable on employer code; the verification note shows how to confirm it in DevTools rather than take our word for it.

Can I apply a patch here as well as create one?

Not currently — this tool only writes patches. A Patch Applier that takes a file plus a unified diff and shows you the result is planned. Until then, `git apply` or `patch -p1` on your own machine remains the way to consume what you generate here.