GOD vs XEX Folder Games: Which Format Should You Use?
The short answer to GOD vs XEX folder games is that neither format wins outright: a GOD package is the tidy, dashboard-native container for a finished library, while an extracted XEX folder is the open, editable form of the same game. Choose GOD when the game is done and should behave like a digital purchase; choose the XEX folder when you still need to touch the files inside.
Both forms come from the same place — an Xbox 360 game, originally on disc as an ISO image — and both only play, on real hardware, on a modded console. The difference is packaging. A GOD package wraps the game into Microsoft’s Games On Demand container format. An XEX folder leaves the game as a loose file tree whose executable is default.xex. Everything in this comparison follows from that one packaging decision.
You can produce GOD packages with the tools on the download page. Extracted folders are what several of those workflows start from or pass through, and the newest GUI in the family, iso2god-next, can even convert an extracted folder (default.xex or default.xbe) directly into a GOD package.
What each format actually is
A GOD package, on disk
GOD is Microsoft’s Games On Demand format — technically a Secure Virtual Optical Disc (SVOD) package, a relative of the STFS container family built to cope with the FATX file system’s limits by splitting content into parts. A conversion produces two things that must stay together: a header file (the package header, which carries the Title ID, Media ID, title, and icon) and a <name>.data folder of part files, Data0000, Data0001, and so on. Integrity is built in: the data is hashed into a SHA-1 Merkle Hash Tree whose root hash sits in the header, so the container can verify its own contents.
An XEX folder, on disk
An XEX folder is the game extracted: the ordinary files of the game laid out as a directory tree, with default.xex as the executable a dashboard or file manager launches. There is no container, no part files, and no hash tree over the whole game — just files, which any PC can browse, copy, and edit with ordinary tools.
The comparison, point by point
| Point | GOD package | Extracted XEX folder |
|---|---|---|
| Structure | Header file plus a .data folder of part files; self-verifying hash tree. | A plain file tree rooted at default.xex; no container. |
| Stock-dashboard visibility | Visible when installed under Content\0000000000000000\<TitleID>\00070000\. | Not a stock-dashboard format; launched through a custom dashboard or file manager. |
| Custom-dashboard visibility | Aurora and similar dashboards scan GOD packages anywhere on disk. | Also scanned and launched by custom dashboards, from wherever the folder sits. |
| Modding the game’s files | Awkward: files are inside the container, so changes mean extracting, editing, and re-converting. | Direct: open the folder, replace or edit the file, done. This is the modding-friendly form. |
| Transfer behaviour | A header plus a set of large part files — a bounded number of substantial files to move. | Potentially very many individual files, including small ones; file-count overhead can make copies and FTP transfers slower and more failure-prone per file. |
| Emulator support (Xenia) | Current Xenia Canary loads GOD packages directly. | Current Xenia Canary also loads an extracted default.xex directly. |
| Licence and content management | Managed as a package; PC-side tools such as 360 Content Manager handle GOD licences. | Managed as files; licence handling applies to packages, not loose folders. |
Visibility: the point people get wrong
The most common confusion in the GOD vs XEX folder choice is assuming the stock dashboard treats them alike. It does not. The stock dashboard understands GOD packages — that is its own digital format — but only in the Content path above. An extracted folder is invisible to it. Custom dashboards such as Aurora change the picture for both formats: they scan storage and list GOD packages and extracted games wherever they are stored. So the real question is not “which format is visible” but “visible where, in which dashboard” — and DLC, note, must sit under Content regardless of where the game itself lives.
Modding: where the XEX folder earns its keep
If you intend to change anything inside the game — swapping a file, applying a community patch to a loose asset, inspecting what a game contains — the extracted folder is the working format. Every edit is a normal file operation, and testing is launching default.xex again. Doing the same work against a GOD package means converting back and forth around every change. A practical pattern is to keep a game as an XEX folder while it is being worked on, then convert the finished result into a GOD package for the library shelf. The conversion direction for that final step is exactly what Iso2God-style tools, and now folder-capable ones such as iso2god-next, are for.
Licence management and 360 Content Manager
GOD packages participate in the console’s content and licence system in a way loose folders do not, and that is where a PC-side manager helps. 360 Content Manager is ConsoleMods’ preferred PC application for managing STFS and SVOD content: copying content to USB or FATX drives and unlocking GOD, XBLA, and DLC licences. If your workflow involves moving packages between drives and consoles, that licence step is part of the GOD route’s real cost and benefit: more structure to manage, in exchange for a package the dashboards treat as proper content. Iso2God’s own output, for the record, is produced with an unlocked licence — which is precisely why it needs a modded console to run.
Which to choose, by situation
- A finished library on a modded console: GOD packages. Tidy, self-contained, visible to the stock dashboard from the Content path and scannable anywhere by Aurora. See Aurora’s GOD handling.
- Games you are actively modding or inspecting: XEX folders, converted to GOD when the work is done.
- Emulation on PC: either. Current Xenia Canary opens both, so keep whichever form you already have — see the Xenia GOD format guide.
- Tight storage: a GOD package made with padding removed is usually the compact, finished form; the storage maths is in the GOD library storage guide.
- Multi-disc games: follow the documented per-disc pattern rather than forcing one format on both discs — install content and GOD packages are often mixed. The padding guide covers the known cases.
The console requirement does not change
Format choice is not a loophole. Both a GOD package from Iso2God and an extracted folder require a modded Xbox 360 (JTAG, RGH, or a BadUpdate-class exploit) on real hardware, or an emulator such as Xenia on PC. A stock retail console plays neither. Any guide implying a format trick unlocks a stock console is wrong, and this unofficial resource site will not pretend otherwise.
Frequently asked questions
Is a GOD package or an XEX folder better?
For a finished library, GOD: it is the dashboard-native, self-contained container. For editing a game’s files, the XEX folder: it is the same game as plain, directly editable files.
Can the stock Xbox 360 dashboard see XEX folder games?
No. The stock dashboard sees GOD packages installed under the Content path. Extracted folders need a custom dashboard or file manager to launch.
Can Xenia use both formats?
Yes. Current Xenia Canary loads GOD packages and extracted default.xex folders directly, as well as ISO images.
What does 360 Content Manager do for GOD games?
It is a PC-side manager for STFS and SVOD content: it copies content to USB and FATX drives and unlocks GOD, XBLA, and DLC licences. ConsoleMods lists it as the preferred application for that job.
Converters for the GOD side of this comparison are on the download page, and more format guides are collected on the Tutorials hub.