Switch XCI Cartridge Images
An XCI is a whole game card copied byte for byte, container and padding included. Here is what sits inside one and how to tell a sound copy from a broken one.
What a cartridge image really is
A Switch XCI is a byte-level image of a retail game card, not a package somebody assembled on a PC. When a card you own is dumped on hardware you own, the reader walks the card from the first byte to the last and writes the result into one file. That file keeps the card's own container, its partition table, its hashes, and the padding the pressing left behind. Nothing is repacked, nothing is renamed, and nothing is dropped because it looked unnecessary.
That one detail explains most of the behavior you meet later. An image of a card behaves like a card. It carries every region the card carried, in the order the card stored them, whether or not you ever read those regions.
How the container is laid out
The container inside is HFS0, a hashed file system used by game cards. A short header sits at the front with a magic value, an entry count, a string table, and one record per region. Each record carries an offset, a length, and a hash, so a reader can verify a region before it reads the contents.
Ahead of that sits the card header, which records the capacity class of the card, the layout of the partitions, and integrity data for the whole surface. Because every offset in the table is absolute, a shortened copy is not a smaller version of the same image. It is a broken one. Any tool that prints the partition table reads the header only, which makes it the quickest sanity check you can run on a file that just finished copying.
The regions you will see listed
A retail pressing usually exposes four regions, and the names are consistent enough that you can read a table at a glance.
- update — the system version pressed with the card, written in the usual
major.minor.patchshape. - normal — a thin bookkeeping region that holds little of interest on its own.
- secure — the large one, holding the title content the card was made to carry.
- logo — optional artwork data, present on some pressings and absent on others.
The update region is the one that surprises people. It is a snapshot from the pressing date, so it is almost always older than whatever your console runs today. Treat it as a fact about the card, not as a statement about your system.
Where packages sit next to card images
A package file is built from the other direction. It is a publisher-style container holding one piece of a title, with no card geometry, no padding, and no pressed firmware region. Our side-by-side page, NSP versus XCI, walks the two formats field by field, so this page stays on the card side of the line.
Two consequences matter in daily use. A card image carries an entire pressing, including regions you may never open. A package carries one component and expects its siblings to arrive as separate files, which is why sets get split across base, update, and add-on packages. Neither shape is more correct than the other; they answer different questions about the same title.
If you want listings rather than format notes, Browse XCI files.
Checks worth running on a fresh dump
Three checks catch nearly every bad copy. Compare the hash you computed at the source with the hash you compute after the transfer; a mismatch usually means the file moved badly rather than that the dump itself failed. Print the partition table and confirm the expected regions are present and that the final offset lands inside the file. Read the title identifier and the version out of the metadata and hold them against the card in your hand, using the identifier pattern rather than guessing from a name.
Storage habits matter as much as tooling. Card images run large, and a filesystem with a four gigabyte ceiling will either refuse the write or split the file behind your back. If the same copy fails the same check twice, stop re-transferring it and Report an issue so someone can look at the source entry instead.