How to fix a source ROM checksum mismatch

A source ROM checksum mismatch means your ROM is not the file the patch expects: usually the wrong region or revision, a header, or an already patched copy.

Find the cause, then fix the input. An override skips the check; it does not repair the ROM.

What does the warning mean?

Apply reports it as Not the expected ROM. Other patchers word it differently: RomPatcher.js shows Source ROM checksum mismatch, and xdelta3 shows target window checksum mismatch. Each usually means the wrong starting file.

The checked bytes differ from the expected file. Compare the same algorithm in Checksum file. BPS/UPS carry checks; for IPS, use the author's notes. Checksums versus filenames explains the evidence.

Which messages are strict?

Open the cards' Checks. A different filename is advisory if size and checksums match. A size or checksum mismatch needs investigation.

Check these causes in order

1. Confirm the author's region, revision, header state, checksum algorithm, disc layout, and patch order. Ask for missing details.
2. Select a clean Original. Use Identify for an unknown source.
3. Compare extracted ROM/track checksums, not ZIP, RVZ, or CHD container hashes.
4. Check the relevant cause below; change one thing at a time.

Wrong region or revision

Use the documented release. Similar filenames or title screens cannot prove identical bytes across regions or revisions.

Wrong file inside an archive

Inspect the card's file list. Choose the expected ROM or track, not simply the largest BIN. Keep CUE/GDI sheets and companion tracks together. Remove and re-add the archive to correct a selection.

Cartridge header differences

A copier header, often 512 bytes, changes offsets and checksums. Keep automatic handling unless instructed otherwise; inspect the patch's Options. rom-weaver checks headered/headerless forms when patch evidence permits. Input handling and the downloaded output's header are separate choices.

Nintendo 64 byte order

.z64, .v64, and .n64 commonly use different byte orders. Automatic handling tries the order proved by the checksum and restores the input order on output. Extensions alone are not proof.

Wrong patch order

If the first patch passes but the next fails, check each input selector and Checks. A dependent patch must follow the result it expects; Original ROM reads the clean source. Restore the author's order and required switches. Use only tested optional combinations.

Already modified files

Return to the clean copy unless the release explicitly requires an incremental input. Patched, trained, trimmed, or edited files can still boot while having wrong bytes. If needed, repeat your legal dumping process.

Once checks match, return to Apply. See why forcing a mismatch is risky or CLI validation for further diagnostics.