Switch-Toolbox was a Windows GUI for Nintendo game file formats, and it is archived

The notice at the top of the README is the current state

The most important paragraph in this repository is the notice, and it is the second thing you see after the title.

This tool is now archived and no longer in development. The XCI/NSP/NCA formats are no longer supported as of the latest due to issues with LibHac. Use other tools to load these formats instead.

That second sentence matters for anyone evaluating the project, because those three formats are the encrypted game containers. A tool that reads them can open a packaged game, and a tool that cannot read them cannot. The author kept the rest of the toolkit and pulled that capability out, with the stated reason being problems with LibHac, the library underneath.

The rest of the download section is consistent with an archived project. The binaries are on the releases page, and the README also says to keep in mind that this tool is still very experimental, that if something breaks from a commit you can download a build manually from the AppVeyor artefacts history by picking a commit and taking the zip from the artefacts tab, and to report anything that breaks in the GitHub issues.

The dates in the repository metadata say the same thing in a different way. There is a single release, named Final and titled Final Release, dated 2024-01-09, and the last push was on 2026-08-26. So commits continued for a while after the final release, and then the project stopped.

For a reader, the practical question is not whether the tool was good but whether the format coverage that remains is what you need, and that is a question about your files rather than about the code.

BFRES is the centre of gravity

Of the many formats listed, BFRES is the one with real depth, and the feature list for it is much longer than the rest of the README.

BFRES is fully supported for Wii U and Switch, and the capabilities are: model importing in DAE, FBX, OBJ and CSV; material editing covering render info, texture mapping and parameters; material copying; import and export of the animation and model sub-sections; deletion, addition and replacement of individual objects from an FMDL; creation of new sub-sections and data; and preview of skeletal, SRT, param, texture pattern and bone visual animations, where the README notes that param animations vary. There is also export and import of fully rigged models with bone support, and conversion of gif files into texture pattern animations, which the README marks as very much work in progress.

The pattern here is the model pipeline. You can bring geometry in from a common interchange format, adjust the material, rig it, and get it back out, with the intermediate representation being a Nintendo format that a game engine will load.

For preview-only formats the tool is thinner, and the difference is instructive. BCRES can be previewed for models, materials and textures. BFSHA can show options, samplers, attributes and uniform blocks. BNSH can extract shader vertex and fragment shaders from variations and programs. EFC can preview effect tables and link PTCL. MSBT gets very basic previewing. And NUT is listed with the note that editing will be implemented soon, which tells you the read side was done first for several formats.

Audio is the other area with real functionality: MP3, OGG, IDSP, HPS, WAV, BFWAV, BFSTM and BCWAV can be listened to and converted between certain formats, with the README crediting VGAudio and CSCore for that.

The format list is long, and the two lists are different lists

The README splits its format coverage into two lists, and the split does more work than a single list would.

The first is Can edit formats, and it is the smaller list. BFRES, BNTX, BFLYT, BFLAN, NUTEXB, XTX, GTX, SARC, BARS, KCL, BFLIM, GFPAK, BEA, AAMP for Switch, 3DS and Wii U, BYAML and BYML for the same three, PTCL for the same three, TMPK, the Crash Bandicoot and Crash Team Racing PAK and IGA archives, and the IGZ textures, plus BFFNT for textures only.

The second is Can preview, and it is much longer: BCRES, BFSHA, BNSH, SHARCFB and SHARC, EFC, NUT, MSBT, the audio formats, NARC, SP2 for Team Sonic Racing, GFMDL, TEX for 3DS, NUSHDB for Switch Namco shaders, SDF for the Snow Drop Engine, NXARC, LZARC, IGA.pak, RARC, GMX for TPHD models, the MKAGPDX model.bin and archive.pac files, ME01 and SA01 archives, Luigi's Mansion 2 Dark Moon archives, models and textures, TPL, TXE, BTI, G1T, and the Ocarina of Time, Majora's Mask and Luigi's Mansion 3DS formats, plus BinGZ for Hyrule Warriors, PAC for Sonic Forces, and GameCube ISOs as a file system.

The last entry on that list, GameCube ISOs, carries the note file system, which means the tool can open an ISO as a container and look inside, not that it decrypts anything.

So the real question for an adopter is narrow: is the format you need in the edit list, the preview list, or neither? The list of formats is long enough that the distinction between the two is easy to skim past, and it is the difference between editing a file and only looking at it.

Building it means Visual Studio 2017 and unblocking downloaded files

The build instructions are short and specific, which is a good sign for a project you might want to fork.

To build, make sure you have Visual Studio installed, the author uses 2017 and older versions may not work, then open the solution, the .sln file, and build the solution as release. It should compile properly on the latest.

Two practical notes follow. In the event that the tool cannot compile, check references, because all the libraries used are stored in the Switch-Toolbox/Lib folder, which is a vendored copy rather than a package reference. And while compiling, Visual Studio might throw errors about files coming from external sources, from the web, and will therefore fail to read and compile them, in which case you go into the project root folder and run the following.

Get-ChildItem -Path "C:\\Full\\Path\\To\\Folder" -Recurse | Unblock-File

That is the Windows equivalent of clearing the quarantine flag on files that came out of a zip, and it is a step a modern Windows developer will recognise.

The repository layout explains the structure. There is Toolbox.sln at the root, a Toolbox/ directory for the application, Switch_Toolbox_Library/ for the format code, BrawlboxHelper/ for the BrawlBox parsing, FBX/ and File_Format_Library/ and File_Format_Library.zip for vendored sources, an Updater/ directory, packages/ for the restored NuGet packages, GL_EditorFramework.dll for the 3D viewer, docs/ and the LICENSE file.

The vendor directory is where most of the real work lives, and that is the point at which a fork becomes a maintenance question rather than a code question.

Almost every format library in the tool is somebody else's project

The credits section is long and specific, and reading it is the fastest way to understand what this tool is. Switch-Toolbox is an integration layer over a set of community format libraries, and the README names them.

For the 3D and model side there is SuperBMDLib, credited to Sage of Mirrors, BrawlLib from BrawlBox for BRRES section conversion, the Assimp devs for their asset library, JuPaHe64 for the base 3D renderer, and the GL Editor Framework also from JuPaHe64. For archive and data formats there is exelix for the BYAML, SARC and KCL libraries, and Syroot for the BinaryData and Maths IO extensions and for the Wii U BFRES library. For compression there is ZstdNet, and for hex editing the tool uses Be.HexEditor by Bernhard Elbl.

The audio path is the same story, with NAudio for audio and MIDI, VGAudio and CSCore, and the README credits those two specifically for the audio conversion feature. The rendering side credits Smash Forge devs for ported code including animation work, an ETC1 encoder and some rendering, Ploaj for a base on the DAE writer, and GDKChan for the SPICA library used with BCH, the PICA shaders used with BCRES, the BCRES structs and some DDS decode methods. Every File Explorer devs, credited as Gericom, provided the Yaz0 and bitmap font work, and AboodXD provided the Yaz0 library along with the texture swizzling for Wii U and Switch, the GTX, XTX and BNTX documentation, and a large part of the Foundation work.

There is a long tail beyond that, including contributions of DDS decode methods, ASTC decoding ported from Ryujinx, FNV hashing, GfPak hash strings, structure references for the Pokemon Switch formats, and LZ77 decompression code ported from QuickBMS.

So the real engineering content of this repository is the integration, the user interface and the format coverage, and the underlying knowledge came from a large number of people who reverse engineered these formats. That is a fair characterisation of most homebrew tooling, and it is also why a fork that needs to support a new format is a real project rather than a weekend task.

GPL-3.0, a final release, and the state of the community links

The licence is GPL-3.0, with the LICENSE file at the repository root, and the repository metadata agrees. That is a copyleft licence, so if you distribute a modified version you owe the source and the notice obligations of the licence, which for a tool that is itself derived from a dozen other libraries is a real consideration when you decide how to publish your fork. This is a licensing fact rather than legal advice, and because many of the vendored libraries have their own terms, the practical question is a stack of licences rather than one.

The project status is unambiguous. The single release is titled Final Release and dated 2024-01-09, the README says the tool is archived and no longer in development, and the last push was on 2026-08-26. The repository is not marked as archived on GitHub, so the code is still there and still readable, but the author's statement is the one to plan around.

The community links are dated in a telling way. The Discord invite is still there, and the tutorial wiki at the GitHub wiki, the issues tracker and the PayPal donation link are all listed. The documentation for the file formats is delegated to external wikis rather than written here, including the mk8.tockdom.com wiki, wiki.oatmealdome.me, the Kinnay Nintendo File Formats wiki and the Avsys file formats wiki, which is where a contributor would look for the actual format specifications.

For a reader deciding whether to use this, the useful summary is that the code is a good reference and a good starting point for a fork, the format documentation lives in other people's wikis, and the tool itself will not gain support for a new console or a new file format from this repository alone.

Editorial conclusion

Switch-Toolbox fits someone who needs to look inside a Nintendo game asset archive, extract a model or a texture, and see the result, and who is working on a Windows machine with Visual Studio. It does not fit a project that needs to load encrypted game containers, since the XCI, NSP and NCA support was removed, and it does not fit a new project, because the project is archived and its last tagged release is the final one from 2024. Before you start from this code, clone it and read the format list yourself, because the readme covers what the tool did rather than what you can rely on today, and check the format documentation wikis it links for the ones you actually need.

Frequently asked questions

Official sources

1. Issues
2. KillzXGaming/Switch-Toolbox on GitHub
3. License: GPL-3.0
4. README
5. Releases