RomsCentral

How to Verify a ROM File on Windows: SHA-256, CRC32, Headers, and Version Mismatches

September 24, 2026

To verify a ROM file, calculate a checksum from the exact file you plan to use and compare it with a trusted reference for the same system, region, revision, and header state. On Windows 10 or Windows 11, PowerShell can calculate SHA-256, SHA-1, and MD5 without installing another program. A matching value confirms that the compared files contain the same bytes. It does not prove that a file is legal to possess, free of malicious surrounding files, or compatible with every emulator.

This guide is for personal dumps, homebrew distributed by its author, and other files you are permitted to use. RomsCentral does not host or link to commercial ROM downloads.

Start with the exact file, not its name

A filename is only a label. Game (USA).gba, Game [!].gba, and Game-v1.1.gba may refer to different data even when the names look authoritative. The opposite is also possible: two differently named files can contain identical bytes.

Before calculating a hash, record four details:

  • the full filename and extension;
  • the exact size in bytes, not only the rounded size shown by File Explorer;
  • whether the file is inside a ZIP, 7Z, or another archive;
  • whether it has already been patched, trimmed, headered, or converted.

If your reference value describes the ROM image inside an archive, hashing the ZIP file will not match it. An archive includes its own directory information and compression data. Extract the permitted image to a working folder, keep your original dump unchanged, and hash the extracted file.

For a broader explanation of images, extensions, and archive containers, first read What Is a ROM File?.

Calculate SHA-256 with PowerShell

Open File Explorer, locate the file, hold Shift, right-click the file, and choose Copy as path. Then open PowerShell or Windows Terminal and run:

Get-FileHash -LiteralPath "C:\ROMs\example.gba" -Algorithm SHA256

Replace the example path with the path to your own file. -LiteralPath is useful because it treats square brackets and other characters in a filename literally instead of interpreting them as wildcard patterns.

PowerShell returns three fields:

  • Algorithm — the calculation used;
  • Hash — the hexadecimal digest to compare;
  • Path — the file that was actually read.

Check the path before comparing anything. A correct hash for the wrong file is still the wrong result.

PowerShell's Get-FileHash uses SHA-256 by default, so this shorter form produces the same algorithm:

Get-FileHash -LiteralPath "C:\ROMs\example.gba"

Writing the algorithm explicitly is clearer when you save the result in a preservation log.

Use the algorithm named by the reference

A SHA-256 value cannot be compared with a SHA-1, MD5, or CRC32 value. The digest lengths differ because the algorithms differ:

Algorithm Typical hexadecimal length Practical use in this workflow
CRC32 8 characters Common in older ROM tools and patch documentation; useful for error detection
MD5 32 characters Legacy identification and simple comparison
SHA-1 40 characters Common in older preservation records and patch notes
SHA-256 64 characters Preferred for a new local integrity record

If a trusted reference supplies SHA-1, calculate SHA-1:

Get-FileHash -LiteralPath "C:\ROMs\example.gba" -Algorithm SHA1

For an MD5 reference:

Get-FileHash -LiteralPath "C:\ROMs\example.gba" -Algorithm MD5

MD5 and SHA-1 remain useful when an existing identification record uses them, but they should not be treated as modern proof against deliberate tampering. For a new preservation record, keep a SHA-256 digest even if you also calculate a legacy value for comparison.

Get-FileHash does not calculate CRC32. If the only available reference is CRC32, use a trusted local tool that explicitly states it hashes the selected file, not the archive container. Do not upload a personal dump to an unknown online checker merely to obtain a checksum.

Compare values without transcription mistakes

Hexadecimal hashes are not case-sensitive, but spaces, missing characters, or copying the wrong line can create a false mismatch. PowerShell can perform the comparison directly:

$actual = (Get-FileHash -LiteralPath "C:\ROMs\example.gba" -Algorithm SHA256).Hash
$expected = "PASTE_EXPECTED_SHA256_HERE"
$actual -eq $expected.Trim().ToUpperInvariant()

Replace the placeholder with the expected SHA-256 value. PowerShell returns True for an exact match and False for a mismatch.

For several personal dumps, export a simple inventory instead of copying values one at a time:

Get-ChildItem "C:\ROMs\Personal-Dumps" -File |
  Get-FileHash -Algorithm SHA256 |
  Export-Csv "C:\ROMs\personal-dump-hashes.csv" -NoTypeInformation

The CSV records the algorithm, digest, and path. Store it separately from the working copies so it remains useful after a drive failure or accidental rename.

What a matching checksum proves

When the algorithm and reference are correct, a match means the byte sequence is the same as the byte sequence used to create the reference. That is a precise but limited conclusion.

A match can confirm that:

  • a copy did not change during transfer;
  • two differently named files contain the same bytes;
  • a working copy still matches your recorded personal dump;
  • a patch is being applied to the exact base revision specified by its author.

A match does not establish copyright permission, ownership, provenance, malware safety, or emulator compatibility. It also does not prove that the reference itself came from a trustworthy source. Keep the checksum together with notes explaining where the reference came from and what version it describes.

Why a ROM checksum does not match

Do not immediately search for a replacement file. A mismatch often has a specific technical cause that can be identified safely.

You hashed the archive instead of the image

Hashing example.zip measures the ZIP container. Hashing example.gba measures the image stored inside it. Extract the permitted file and repeat the calculation on the same object described by the reference.

The region or revision is different

Region variants and later revisions can have different program data. A label such as USA, Europe, Japan, Rev 1, or v1.1 is part of the identity, not decorative filename text. Compare only against a reference that names the same release.

A copier header is present or absent

Some older cartridge images circulate with an added copier header. The playable content may be closely related, but adding or removing even one byte changes every cryptographic hash. SNES images are a common place to encounter header-related mismatches.

Do not strip a header from your only copy. Preserve the original, duplicate it, and modify only the working copy after confirming the expected format from reliable emulator or patch documentation.

The file was already patched

A translation, bug fix, randomizer, or improvement patch changes bytes and therefore changes the hash. Patch documentation normally identifies the required unmodified base image. Verify the base copy before applying the patch, then record a second checksum for the patched result.

The dump or copy is incomplete

An interrupted transfer, failing storage device, or unsuccessful dumping process can truncate or alter data. Compare the exact byte size, create a fresh personal dump when possible, and calculate the hash again. Repeatedly renaming or recompressing the same damaged file will not repair it.

The wrong algorithm was selected

An eight-character CRC32 cannot equal a 64-character SHA-256 value. Confirm the algorithm before investigating more complicated causes.

A repeatable verification workflow

Use this sequence when adding a permitted image to an emulator library:

  1. Keep the original personal dump read-only.
  2. Create a separate working copy.
  3. Record the system, region, revision, extension, and exact byte size.
  4. Calculate SHA-256 for your own integrity record.
  5. Calculate the legacy algorithm only when a trusted reference requires it.
  6. Compare the value before renaming, patching, trimming, or converting the file.
  7. Test the verified working copy with default emulator settings.
  8. Record any later patch or conversion as a separate derivative with its own checksum.
  9. Back up save files separately from emulator save states.

If the emulator reports missing system software, checksum verification of the game image will not solve that separate dependency. See BIOS and Firmware in Emulation. If progress files are the problem, use Save Files vs Save States to identify which file type needs to be restored.

Verification checklist

Before treating a result as meaningful, confirm all of the following:

  • You hashed the intended file, not a shortcut or archive container.
  • The algorithm matches the reference.
  • The reference names the same system, region, revision, and header state.
  • The file was verified before patching or conversion.
  • A matching value is being used only as evidence of byte-for-byte identity.
  • The original personal dump remains unchanged.

That approach turns a checksum from a mysterious string into a useful troubleshooting record. It also prevents a common mistake: replacing a valid file when the real difference is only an archive, header, patch, or revision mismatch.