Cartridge Dump Versus a Nintendo Switch XCI Image
A card is a physical object with a resale value and a scratch on the label. An image is bits. Here is what survives the trip from one to the other.
Two objects that are easy to confuse
A nintendo switch xci is a file. A cartridge is a small piece of plastic with a chip inside it, a printed label and a bitter coating that exists purely to stop toddlers swallowing it. People discuss the two as if they were the same thing wearing different clothes, and that shortcut causes most of the confusion around card backups. They are related the way a photograph is related to a room: one faithfully records the other and is not remotely a substitute for it.
The image is a record of what the card carries. The card is a manufactured item with a serial number, a scratch on the label from the bottom of a bag, a resale value on the second-hand market and a slot it physically occupies. Nothing in the second list crosses over into the first, and that is the practical difference this page is about.
Format mechanics, structure and handling live on the image format page, and the current inventory sits under Browse XCI files. This one stays on the comparison, because the question people actually arrive with is whether the file lets them stop caring about the card.
What survives the trip, and what does not
The data survives. The software that shipped on the card, its structure, the version pressed at manufacturing time: all of that is what an image is for. Everything else about the card stays with the card.
- The entitlement. Owning software on a card means owning the card. Hand it over and you handed over the thing that made the copy defensible.
- The convenience. A card plays without consuming your storage. An image is a file that has to live somewhere and something has to be willing to read it.
- The resale value. Second-hand cards hold value. Files do not have a second-hand market and never will.
- The wear. Contacts oxidize, labels peel, cases split. This is the one column where the file genuinely wins, because bits do not care how long they sat in a drawer.
That last point is the honest argument for imaging a collection at all. Physical media degrades slowly and unpredictably, and a shelf of cards read once and recorded is a shelf that has already survived its own worst outcome. The argument does not extend to cards you no longer possess.
Why the file is bigger than you expected
People are routinely surprised that a card image weighs more than the shop version of the same software. The reason is structural rather than mysterious. A card image records the layout of the card, padding included, along with the card-level material a shop package has no reason to carry. Two containers holding the same title are still two different containers.
Which means storage planning has to start from the number shown on the row you are looking at rather than from a figure someone quoted for a different shape of the same software. Nobody should be reciting sizes for named titles from memory, and a size that arrives without a listing attached is a guess. If you are working out where the files go, the storage page covers capacity and formatting choices before you commit to a layout.
The version question follows the same discipline. Cards ship with whatever build was pressed at manufacturing time, which is often earlier than the current one, and that build is what the image records. Read version fields as a major.minor.patch shape and compare against what your console reports in System settings. A launch build written as 1.0.0 is a normal thing to find inside an image of an older card, not a defect.
The line that decides whether any of this is fine
Keep the card. That is the entire ethical and practical rule, and it is short enough to remember at the moment it matters, which is usually the moment someone offers you cash for a box of games.
An image made from a card you own, kept for your own use, on hardware you own, is the framing this bench works within. It is not a universal permission slip; rules differ by country and nothing here is legal advice. An image kept after the card left your possession is a different arrangement no matter how the file was produced, and an image of a card you never held is not a backup of anything, it is just a file with a story attached.
The same logic covers borrowed cards, rentals and the friend who is definitely getting it back next week. The question is never how the bits were produced. It is who holds the object those bits came from.
Choosing which shape to keep
Match the shape to the provenance. Software bought on a card belongs in your archive as a card image; software bought as a shop entitlement belongs there as a package. That sounds like pedantry until you are three years and four hundred entries into a collection and trying to remember which titles you can still put your hands on. Provenance-matched archives answer that question by themselves. Mixed ones require a spreadsheet and a good memory.
There is a compatibility dimension too, and it points in the opposite direction from the tidiness argument. Packages are the shape most tooling expects, and card images are the shape with more variation in how things handle them. If you want the two compared at the level of what each format contains rather than where each came from, Read NSP versus XCI is the page for that, and matching a row to a package covers the identifier checks that apply either way.
Whichever you keep, verify it while nothing is wrong. Confirm the file finished, confirm the identifier inside matches what the listing claimed, and note the date. If a row here turns out to describe something the file does not contain, Report an issue or Open a ticket so it gets corrected. An archive nobody ever tested is a filing cabinet full of assumptions.