Choosing a patch format
BPS, IPS, xdelta, PPF, and a dozen more. This guide explains what actually separates them and which one to publish in.
Applying a patch? Use the format you received
Use whatever format you were handed. rom-weaver applies 21 patch families; the full format table shows whether yours is supported before you consider converting it.
Converting a patch to another format does not fix a checksum error either. The format is not the problem; the starting file is. Go to Fix a checksum error instead.
This guide is for people publishing a patch.
What separates patch formats?
Every format on this page records the same thing: which bytes changed. What separates them is how much they know about the file you are supposed to start from.
Some store a checksum of the original inside the patch. When a user feeds in the wrong file, the patcher stops and says so. Some store nothing, so the patcher happily applies your changes to the wrong game and hands back a broken file that looks fine until it is not.
That difference decides most of your choice. For cartridge-sized files, size and speed usually matter less than whether users can detect a mistake. Disc-sized files make patch size and tool support more important.
No format records everything, though. None of them know which region you meant or which revision, so write the region, the revision, the header state, the patch order, and the expected checksums in your release notes regardless.
BPS
BPS stores a checksum of the original, of the finished file, and of the patch itself. A patcher can therefore reject the wrong starting file, and confirm the result came out right.
That makes it a strong default for cartridge games when your audience has a BPS-compatible patcher. rom-weaver applies and creates BPS; to publish one, see the browser or CLI create guide.
IPS and IPS32
IPS is one of the oldest and most widely supported patch formats. It is a plain list of "at this offset, write these bytes." Nothing else. In particular, it stores no checksum of the original, so an IPS patcher cannot confirm it was handed the right starting file. rom-weaver reads the record layout for hints (see How rom-weaver picks a patch's bytes), but hints are not proof.
Pick IPS when reaching old tools matters more than catching user error, and always publish the expected checksums beside the download.
IPS also has a hard limit built into its 24-bit offsets: it cannot encode a change that starts at or beyond 16 MiB. Create stops offering IPS when either input reaches that boundary. IPS32 widens the offsets so larger files work. rom-weaver applies and creates both.
UPS
UPS stores checksums of the input and the output, so it can catch a wrong starting file the way BPS does.
Pick UPS when the tools or the community you are publishing into expect it. rom-weaver applies and creates it.
xdelta and VCDIFF
VCDIFF is a general-purpose format for describing the difference between any two files. xdelta is the widely used tool built around it, and its name is what most people say.
It handles large binaries and disc images well, which is why disc projects reach for it. Patches turn up as .xdelta, .delta, .dat, and .vcdiff.
Do not assume an xdelta patch identifies its source for you; that depends on how it was made. Publish the checksums and the exact command you expect users to run. rom-weaver applies and creates xdelta and VCDIFF.
PPF
PPF was designed for disc patching and remains in use. Different PPF versions can do different things, so your release notes carry more weight than usual here.
Discs need more care than cartridges in general. A file ending in .bin or .iso tells you almost nothing: track layout, image format, and which dump it came from all change the bytes. Get your users onto the exact disc image you built against before you treat a mismatch as a patcher bug.
rom-weaver applies and creates PPF.
Other supported formats
rom-weaver also handles SOLID, GDIFF, HDiffPatch/HPatchZ, APS, APSGBA, RUP, PAT, EBP, BDF/BSDIFF40, BSP, MOD, DLDI, DPS, and the Dreamcast-specific DCP workflow. Support for applying and support for creating are not the same for every one of these.
The full format table is the authoritative list of names, extensions, and what rom-weaver can currently apply and create.
How rom-weaver picks a patch's bytes
Some dumps contain a copier header before the ROM data. Others, especially Nintendo 64 dumps, store the same data in different byte orders. A patch needs the form its author used.
rom-weaver first compares the available expected checksums against supported variants. Explicit checks and bundle checks take precedence over a patch's own source checks. File size alone can distinguish two candidate layouts, but cannot identify a ROM.
For the first patch, missing checksum evidence can trigger inference from patch records, validation failures, and the resulting platform header. N64 inference can also use a rewritten boot checksum. These are fallbacks, not checksum proof. Later chain steps use checksum evidence rather than repeating first-patch inference.
When the evidence cannot distinguish candidates, rom-weaver keeps the existing form. A reported inference still needs checking against the author's expected result. Publishing source and output checksums removes that uncertainty.
The architecture guide records the decision rules and implementation paths. Fix a checksum error covers what to check in the browser.
Interleaved Genesis dumps are not a header question
A Genesis .smd dump also opens with 512 bytes, and it is tempting to treat those as one more removable header. They are not. Behind them the ROM is stored in 16 KiB blocks with each block's odd bytes written first and its even bytes second, so removing the 512 bytes leaves interleaved data rather than a shorter ROM. There is no offset a patch could be shifted by to fit it.
rom-weaver therefore does not offer a headerless form behind an .smd header. It recognises the dump for what it is and leaves it alone, which also stops a misnamed .smd from being read as a copier-headered SNES ROM - every .smd file happens to have exactly the size a copier-headered dump has.
Which format should I choose?
- Applying somebody's patch: the format they gave you, with the exact file they documented.
- Publishing for a cartridge game: BPS, for the checksums it carries.
- Publishing where old patchers must work: IPS, with checksums in your release notes.
- Publishing for a disc or a very large file: xdelta/VCDIFF or PPF, or whatever that platform's community already uses.
- Publishing several patches at once: any of the above, plus a rom-weaver bundle to record the order, the optional pieces, and the checksums.
Picked one? Create a patch walks through making it and, more importantly, testing it. Back to the guide index.