Skip to content
EZ ROM Patcher

Fixing ROM patch errors

Short answer

Most ROM patch failures come from four causes: the base ROM is a different region or revision, the ROM has a copier header the patch does not expect, the patch is an xdelta file built with secondary compression, or the ROM was already patched. Each produces a distinct error you can diagnose.

Error: source checksum mismatch

The patch carries a checksum of the ROM it was built from, and yours does not match. The patch is protecting you here. Work through these in order:

  1. Check for a copier header

    If the patcher offers a "remove header" checkbox, your ROM is headered. Toggle it and try again. This alone fixes most SNES and NES failures.

  2. Confirm the region and revision

    USA, Europe and Japan releases are different files, and so are revision 1.0 and 1.1. Read the hack’s readme for the exact base it expects.

  3. Check the ROM is not already patched

    Applying a patch to an already-patched ROM never works. Start from a clean dump.

  4. Verify the ROM against a database

    Use the checksum tool and compare to No-Intro or the author’s published hash to confirm your dump is good.

Error: invalid or unrecognised patch file

The patcher reads the first bytes of a file to identify the format. This error means those bytes matched nothing it knows.

  • The download was incomplete or corrupted. Re-download and compare file sizes.
  • The file is actually an archive with an unusual extension. Try renaming it to .zip.
  • You selected the ROM in the patch field by mistake.
  • The file is a .rar or .7z archive. The patcher handles zip only; extract these first.

Error: not implemented: secondary decompressor

This is specific to xdelta patches. VCDIFF allows an optional extra compression layer, and the browser engine does not implement those decompressors. Your ROM is fine; the patch simply uses a feature that is not supported here.

  • Ask the author for a patch built with xdelta3 -e -S none.
  • Or apply this one with the xdelta3 command line tool on a desktop.

The patch applied but the game is broken

This is the signature of a format with no validation: IPS, PPF 1.0 and BSDiff apply to whatever you give them. If the base ROM was wrong, you get a corrupt result and no error.

Verify your base ROM’s checksum against the author’s stated value, then patch again from a clean copy.

The page freezes or runs out of memory

Patching loads the whole file into memory. A 700 MB disc image needs well over a gigabyte of headroom once the output is built alongside it. Close other tabs, or use a desktop browser rather than a phone.

Frequently asked questions

What does "source checksum mismatch" actually mean?

The patch stores a checksum of the ROM it was created from, and the file you supplied hashes to something different. Usually that is a copier header, a different region or revision, or an already-patched ROM.

Why does my patch work in another tool but not here?

The usual case is an xdelta patch using secondary compression, which the desktop xdelta3 tool supports and the browser engine does not. Some tools also apply patches without validating checksums, which means they "work" while silently producing a corrupt ROM.

I removed the header and it still fails. What else could it be?

Region or revision is the next thing to check. Compare your ROM’s CRC32 against the exact value in the hack’s readme rather than assuming any USA copy will do.

Can a bad patch damage my original ROM?

No. The original file is only ever read. The patched result is written as a separate download.

Keep reading

Last reviewed