Unified Diff Generator
Turn two texts into a git patch.
About Unified Diff Generator
A unified diff is the format git prints and the format patch files use: changed lines marked with plus and minus, grouped into hunks with a few lines of context, and headed by line numbers so the receiving side knows exactly where each change belongs. Writing one by hand is impractical because the hunk headers must count lines precisely. This generator does the counting. Paste the original and the changed text, name the files as they should appear in the patch, choose how many context lines surround each change, and the output is a real patch that git apply or patch -p1 accepts. Edge cases that usually break hand-made patches are handled, including files that do not end with a newline, which get the standard marker. The comparison runs in your browser, so unreleased code can be turned into a patch privately.
How to Use Unified Diff Generator
Paste both versions
Put the original text on the left and the changed text on the right. Whole files or short snippets both work; the diff is line based.
Name the files
Set the original and changed file names so the patch header reads correctly. Git convention prefixes them as a/ and b/, which the defaults already follow.
Choose context lines
Context lines are the unchanged neighbors shown around each edit. Three is the git default and usually right; more context makes patches apply across slightly shifted files.
Generate and apply
Click Generate patch, then download or copy the result and run git apply file.patch inside the target repository. Identical inputs produce a friendly message instead of an empty patch.
Why Use Unified Diff Generator: Common Use Cases
Sending a fix without push access
Produce a patch file from before and after versions and attach it to an issue or email, so a maintainer can apply your exact change with one command.
Documenting a manual edit
When a config file was fixed on a server by hand, capture the change as a patch and commit it properly through the normal code review flow.
Reviewing a colleague's description of changes
Ask for the before and after text rather than a screenshot, generate the diff, and read the actual delta without tool-specific markup getting in the way.
Applying one file's changes across environments
Turn a hand-tuned production configuration into a patch and apply it to staging, so both environments converge without copy-paste errors.
Unified Diff Generator Specifications
| Input Formats | Original text, Changed text, File names, Context line count |
|---|---|
| Output Formats | Unified diff patch file |
| File Size Limit | No strict limit (dependent on device memory) |
| Processing Engine | 100% Client-side (Runs locally in your browser) |
| Data Retention | Files never leave your device |
| Batch Processing | Single file processing |
Tips for Unified Diff Generator
Keep some context lines. A patch with zero context only applies if the surrounding file matches exactly, while three lines of context gives git room to locate the hunk.
Patches apply to a clean working tree. Run
git statusfirst, because local edits in the same region make even a correct patch refuse to apply.A trailing newline matters. Files saved without a final newline are handled with the standard marker, but mixing conventions between sides produces noisy diffs.
To read a diff rather than create one, Diff Checker shows the changes as colored inline output, which is friendlier for review.
For line-level cleanup before comparing, such as trimming trailing spaces that create phantom changes, Line Tools does it in a couple of clicks.
Frequently Asked Questions
What is a hunk?
A hunk is one contiguous cluster of changes plus its surrounding context lines, introduced by a header like @@ -12,7 +12,8 @@ that counts the lines in each file. Large edits can produce several hunks separated by unchanged stretches.
Can I apply this patch with the plain patch command?
Yes. The format is the standard unified diff, so patch -p1 < file.patch works wherever git is not installed. Strip levels differ between tools, which is why the file names use the a/ and b/ convention.
Why does git apply reject a patch that looks correct?
Rejection means the context lines do not match the target file at the stated location. The usual causes are an edited or outdated target, wrong file names in the header, or line ending differences between systems.
How are binary files handled?
They are not. The comparison is line-based text only, which covers source code, configuration, and documents. For binary assets, share the files themselves rather than a patch.
What does the backslash marker about newlines mean?
It flags a file that does not end with a newline character, which is technically malformed for many tools. The patch preserves that fact exactly, so applying it reproduces the original situation instead of silently fixing it.
Can I reverse a patch?
Yes. git apply -R file.patch undoes the change, provided the target still matches the post-patch state. That reversibility is one reason patches are preferred over emailing whole files.