In short
- XD3_INVALID_INPUT is xdelta3’s way of saying the input is wrong: your source file doesn’t match the one the patch was created from.
- The patch is almost never broken. Get the exact source version the patch author names — same region, revision and format.
- Verify with a checksum before patching again; guessing wastes less time than re-downloading blindly.
- Turning off checksum validation does not fix it — it just writes a corrupt file instead of stopping.
What the error looks like
In Delta Patcher, the friendly dialog reads:
The patch could not be applied:
The file you are trying to patch is not the right one.
Open the log (bottom-right button) and you’ll see the raw xdelta3 message:
An error has occurred: xdelta3: target window checksum mismatch: XD3_INVALID_INPUTOn the xdelta3 command line the same failure appears as:
xdelta3: target window checksum mismatch: XD3_INVALID_INPUT
xdelta3: normally this indicates that the source file is incorrectBoth messages describe one situation: xdelta3 started rebuilding the output from your source file, checked its work against the checksums stored in the patch, and the numbers didn’t match. It stopped rather than write garbage. For the full mechanics, see fixing target window checksum mismatch.
What XD3_INVALID_INPUT actually means
xdelta3 names its errors after the decoder’s internal states. XD3_INVALID_INPUT literally means “the input you gave me is invalid for this operation” — and for decoding, the input under suspicion is the source file, not the patch. The xdelta documentation states this error “almost always means you supplied the wrong source file.”
This is worth internalising because every instinct points the wrong way: people re-download the patch, try a different patcher, or toggle settings. None of that helps, because the patch was verified good the moment it was created — it applied cleanly to the author’s source file. The variable is always your file.
The fix sequence, in order
-
Read what the patch author requires
Open the patch’s README, its download page, or the Patch info tooltip Delta Patcher shows when you load the patch. Write down the exact file name, region (USA / Europe / Japan), revision (1.0, 1.1, Rev A), file size and any published checksum. If the author lists a checksum, that value is the ground truth — everything else is just a hint.
-
Check your file against that requirement
Compare file size first: it’s the fastest filter. Then calculate a checksum with the same algorithm the author published and compare the values. How to verify a source file covers the tools on every platform. If size or checksum differ, stop — you have the wrong file, and no setting will change that.
-
Fix the usual suspects
Work through the differences that change bytes without changing the game: wrong region or revision, a trimmed dump, a headered vs unheadered ROM, a converted format, or a file you already patched once. Each of these is a different file as far as xdelta3 is concerned. See wrong ROM version for the version/region detective work.
-
Get the exact source and re-verify
Make a fresh copy from media you own, matching the author’s specification exactly. Re-check size and checksum. Only when both match should you patch again.
-
Patch a clean copy with validation on
Tick Backup original file in the gear menu, leave Checksum validation on, and apply. With the right source, XD3_INVALID_INPUT disappears.
Things that won’t fix it
| Attempt | Why it fails |
|---|---|
| Re-downloading the same patch | The patch already worked on the author’s file; yours is the variable |
| Trying a different patcher | xdelta3, Delta Patcher and online tools all run the same check |
| Disabling checksum validation | Skips the check and writes a corrupt file instead of erroring |
| Renaming the file | xdelta3 reads bytes, not file names |
| Patching a zipped ROM | Extract it first — patchers can’t read inside archives, and this errors differently |
If you made the patch yourself
Seeing XD3_INVALID_INPUT on a patch you created usually means the source file changed between creating the patch and testing it — a common slip is creating the patch from one dump and testing against another. Re-create the patch from the exact file you distribute the checksum for, and publish that checksum in the patch description. Delta Patcher’s Add Checksum to patch option (create mode) embeds per-window checksums so your users get this clear error instead of silent corruption.
Frequently asked questions
Does XD3_INVALID_INPUT mean the patch is corrupted?
Almost never. A corrupted patch usually fails earlier, with a read error or an obviously truncated file. XD3_INVALID_INPUT specifically means the decoder got far enough to compare checksums, which requires a structurally sound patch and a wrong source file.
My file is the right game and region. Why does it still fail?
“Right game” isn’t precise enough — the patch needs the right bytes. Revision differences (1.0 vs 1.1), trimmed vs untrimmed dumps, headered vs unheadered ROMs, and different dump tools all produce different bytes for the same game. Check the exact checksum the author published.
Can I force the patch to apply anyway?
You can disable checksum validation, but the output will be corrupt: bytes from the wrong source get woven into the result. It might boot and it might not, but it isn’t the hack the author released. Find the right source instead.
The same patch worked for my friend. What’s different?
Their source file. Two downloads of “the same game” are routinely different revisions, regions or trims. Ask your friend for the file’s checksum (or size) and compare it with yours — that usually settles it in seconds.