Switch NSP Container Format
An NSP is an archive, not a disc image. This page opens it up: the PFS0 wrapper, the NCA files inside, and the metadata record that describes the title.
What the container really is
People meet the term switch nsp as a file extension and assume it is a disc image, because that is the mental model most consoles trained us on. It is not. Strip the name away and you have a small archive: a fixed header, a table saying where each member file starts and how long it is, a block of names, then the payload glued on the end. Nothing more clever than that.
That design has a practical consequence. An archive can be read without being fully unpacked, so a tool can look at the table, pull out the one member it cares about, and ignore the rest. It also means the interesting structure is one level deeper than the extension. The extension is the box; the content archives inside are where the title actually lives.
If you only need the practical difference between the two formats this site indexes, the existing comparison at Read NSP versus XCI is the shorter road. This page assumes you already read it and want the layer underneath.
PFS0: header, table, names, data
The archive layout is called PFS0, and the first four bytes of the file spell exactly that. After the magic value comes the number of entries, the size of the string table, and a small amount of padding. Then the entry records: for each member file, an offset into the data area, a length, and a pointer into the names block. The names block follows, and the raw member data sits after it.
Two things fall out of this. First, an NSP has no compression — the members sit in the file at full size, which is why the archive size is essentially the sum of what it contains. Second, member order is a property of the table, not of the payload, so two packages holding identical content can differ byte for byte and still be functionally the same. That is worth remembering before you conclude a checksum mismatch means a bad file.
NCA: where the content actually lives
The members you find in the table are almost all content archives, and their names are long strings of hex. Each one begins with an encrypted header stating what it holds and how its sections are hashed, then carries the sections themselves. The header key belongs to the console, not to the file, which is why an archive can be listed and copied by any tool while its contents stay unreadable without the hardware side.
The content types are worth knowing by role. Program archives hold executable code and the read-only filesystem with the assets. Control archives hold the icon and the localized names — the strings a menu shows. Meta archives hold the record described in the next section. Legal-information and offline-manual archives hold text and markup, and they are frequently the smallest members in the package.
An update package is built from the same parts as a base package. Same wrapper, same content types, different title version in the metadata. Downloadable content follows the same shape again. Nothing in the format marks one as a game and another as an add-on; the metadata does.
CNMT, tickets and certificates
One member is the content meta record, usually visible in a listing as a name ending in .cnmt.nca. It states the title ID, the title version, the content type of the package as a whole, the required system version, and the hash of every other content archive in the set. This is the closest thing to a manifest an NSP has, and it is the field a verifying tool checks before anything else.
Some packages also carry a .tik ticket and a .cert certificate. Those appear when the content uses title key encryption, which is how shop-delivered titles arrive. A ticket can be personalized to the account that obtained the title, which is one reason a package that works on one bench behaves differently on another. Dumps sourced from a cartridge normally have no ticket at all, and the absence is not damage.
What an installer program expects
Two installer programs come up constantly in backup discussions: DBI and Tinfoil. Both are file managers and installers rather than players — they read a package, check its metadata, and register the content archives with the system. Both accept NSP input as their normal diet; support for the whole-card format differs between them and between versions, which is the practical reason people keep asking which format to grab. This site documents what the files are and publishes no setup instructions for either program.
The takeaway for format questions is narrow: an installer cares about the metadata record and the content archives, not about the wrapper. That is why the archive layout described above is boring by design.
How this maps to a catalog row
A row in this index shows the container format, a size, a title ID, and a checksum, because those are the four things you can verify without opening anything. The size should match the sum of the members. The title ID should match the metadata record. The checksum covers the whole archive as it was indexed. Reading those fields properly is its own topic in how to read an NSP listing.
To move from reading to browsing, use Browse NSP files for this format or Open the catalog for both. If a package is missing a title you expected to find, Open a ticket. If a listed field contradicts the file, Report an issue.