How to verify a ROM with checksums
To verify a ROM, calculate its CRC32, MD5 or SHA-1 hash and compare it to the value published by the patch author or a database such as No-Intro. If the hashes match exactly, you have the right file. If they do not, the patch will either refuse to apply or produce a broken ROM.
CRC32, MD5 or SHA-1: which should you use?
| Hash | Length | Where you see it |
|---|---|---|
| CRC32 | 8 hex characters | Romhack readmes, No-Intro DAT files, .sfv files |
| MD5 | 32 hex characters | Patch author documentation, redump records |
| SHA-1 | 40 hex characters | No-Intro and redump databases, the most rigorous of the three |
For confirming you have the right ROM, any of them is fine. CRC32 is the one romhack authors quote most often because it is short enough to read out. SHA-1 is what preservation databases use because collisions are far harder to produce.
Why your checksum might not match
- Your ROM has a copier header and the published hash is for the unheadered file, or the other way around. A 512-byte SNES header changes every hash completely.
- You have a different region or revision. USA 1.0 and USA 1.1 are different files.
- The ROM is a bad dump or was truncated by an interrupted download.
- The ROM has already been patched.
- You hashed the zip file rather than the ROM inside it.
Checking against .sfv, .md5 and .sha1 files
These are plain text files listing filenames and their expected hashes, one per line. Load one into the checksum tool alongside your files and each entry is checked and marked as matching or not.
Chrono Trigger (USA).sfc 2d206bf7
Final Fantasy III (USA).sfc a27f1c7aFrequently asked questions
What is a CRC32 and why do romhacks list it?
CRC32 is a 32-bit checksum shown as eight hexadecimal characters. It is quick to compute and short enough to print in a readme, which made it the romhacking scene’s standard way to identify an exact ROM file.
My checksum does not match. Is my ROM bad?
Not necessarily. The most common causes are a copier header, a different regional release or revision, or a ROM that was already patched. A genuinely corrupt dump is less common than any of those.
Are my files uploaded when I check a checksum?
No. Hashing happens in a Web Worker on your own device. Nothing is transmitted.
Is MD5 safe to use for verifying ROMs?
For confirming file identity, yes. MD5 is broken for security purposes because attackers can construct collisions deliberately, but that is irrelevant when you are checking that a download matches a known file.