Fix a checksum error in the browser

rom-weaver says the bytes do not match what a patch or bundle expects. Stop there and find the difference before creating an output.

01What does the warning mean?

A checksum is a fingerprint calculated from every byte in a file. Change one byte and the fingerprint changes. Rename the file and the checksum stays the same because the filename is not part of its contents.

When a checksum does not match, your file differs from the expected file by at least one byte. The message does not tell you why. It tells you that continuing would use a different starting point from the one the patch author tested.

BPS and UPS can carry expected checksums inside the patch. Other formats, such as IPS, may not know what Original they need. In those cases, compare the checksums shown by rom-weaver with the values in the author's notes.

Compare the same algorithm. CRC32, SHA-1, and SHA-256 fingerprints for one file look unrelated.

02Which messages are strict?

The Weave cards separate clues from proof.

An expected filename mismatch is advisory. Authors often write a useful name into a bundle, but users may legally dump or rename the same bytes under another name. If size and checksum match, a different name alone does not make the ROM wrong.

An expected checksum mismatch is strict. An expected size mismatch is also strict. Those messages describe the file contents, not the label on the file.

Open Checks on the ROM and patch cards. Read the expected value and actual value carefully. A green match means that exact check passed at that step. A red mismatch is the problem to solve.

03Check these causes in order

Change one thing at a time:

1. Reread the release notes. Write down region, revision, checksum algorithm, header state, disc layout, and patch order.
2. Return to a clean Original. Do not use a file that was already patched, trimmed, trained, or edited.
3. Confirm the ROM card shows the file you meant to select.
4. Compare its checksum with the author's value using the same algorithm.
5. If the ROM came from an archive, confirm the selected entry.
6. Check the cartridge header or Nintendo 64 byte order when relevant.
7. Put patches back into the documented order.
8. Retry only after you can name what changed.

Most problems are found in the first four steps.

04Wrong region or revision

USA, Japanese, and European releases of the same title are different files. Text, code, timing, and data may sit at different offsets. A patch built for one release will not safely apply to another.

Revisions are harder to spot. Rev 1 may look and play like Rev 0 while fixing a few bytes at the exact locations a patch changes. The title screen cannot tell you which one you have. The checksum can.

Use the exact release the author documented. Do not hunt for a random download with a promising filename. Ask the author or community for the expected checksum and release details.

05Wrong file inside an archive

An archive may contain several ROMs, disc tracks, save files, readmes, or regional variants. rom-weaver asks you to choose when it cannot prove one candidate is correct.

Open the archive's file list in the card and compare it with the release notes. For a multi-track disc, keep the cue sheet and all tracks together. Choosing a large .bin file just because it looks important can still select the wrong track or layout.

Remove the wrong card, add the archive again, and choose the correct entry. Then compare the checksum before patching.

06Cartridge header differences

Some cartridge dumps have a small copier header before the game data. A common size is 512 bytes. The header is not part of the game, but it shifts every later byte and changes the checksum.

rom-weaver checks headered and headerless forms when the patch provides enough information. The patch card's Options can show header handling for systems where it applies.

Leave automatic handling selected unless the author gives a reason to change it. Do not strip a header on a hunch. Compare the card's checks with the author's expected value first.

The output header is a separate choice. One setting controls the bytes a patch receives, while the output setting controls the form of the downloaded result.

07Nintendo 64 byte order

Nintendo 64 dumps are commonly stored in three byte orders, often indicated by .z64, .v64, and .n64. They can represent the same game while producing different checksums because their bytes are arranged differently.

Automatic handling tries the order proved by the patch checksum and writes the result back in the input's order. Keep automatic handling unless the release notes explicitly require another form.

An extension is still only a clue. Use the checksum in the ROM card to identify the actual bytes.

08Wrong patch order

With several patches, each one runs on the previous patch's result. A later patch may expect the translation output, not the clean game.

In 0x03 Patches, drag the numbered handles into the author's order. Open Checks on each card. The expected input for one step should match the actual output state from the step above it.

Do not turn off a required base patch to get past a warning. Optional switches are safe only for combinations the release author tested.

If you started from a bundle, its saved order should already be correct. A manual reorder is a sign to reread the bundle's release notes.

09Already modified files

Translations, trainers, patches from another project, trimming tools, and save data can all change a ROM. A file may boot normally and still be the wrong Original.

Go back to the clean copy you preserved before patching. If you do not have a known-good copy, obtain it again through the same legal dumping process and check its fingerprint.

Do not use the output from an older release unless the new patch explicitly says it is incremental.

10Why is forcing risky?

A checksum override skips the safety check. It does not repair the file.

The patch may still create a download that boots and fails much later. Code can jump to the wrong data, text can overwrite another table, or a save can become corrupt hours into play. A successful download is not proof of a correct result.

Overrides exist for authors doing controlled research and recovery. For normal use, find the matching Original instead.

Once the checks match, return to Apply a ROM patch. If you need terminal diagnostics, the CLI patch validation reference keeps those commands in one place. The FAQ covers related filename, privacy, and format questions.