XGD2 vs XGD3 is, at heart, a before-and-after story: XGD2 is the launch-era Xbox 360 disc format, and XGD3 is its 2011 successor, which gave developers roughly an extra gigabyte of data on each disc — about 8.13 GB in total against the roughly 7 GB class of XGD2. For Iso2God conversion, the practical news is reassuring: the modern converter iso2god-rs detects and accepts XGD1, XGD2, XGD3, and XSF images, so the format on your disc rarely decides whether a conversion is possible.

These letters get thrown around in forums as if they were quality grades or copy-protection settings you can toggle. They are neither. They are successive generations of the Xbox Disc (XGD) layout — the physical and logical format a game was mastered in — and which one you have is fixed by when and how the game was produced. This page walks the generations in order, states only what contemporary sources support, and finishes with what each format actually means at conversion time.

If you have an XGD3 image in front of you and a problem to solve, the dedicated walkthrough is the XGD3 Iso2God guide. All of the converters mentioned are on the download page.

The four names, in era order

XGD1: the original Xbox format

XGD1 is where the family starts: the game disc format of the original Xbox. It matters to an Iso2God reader for one concrete reason — the conversion lineage never dropped it. The original Iso2God converted original-Xbox ISOs as well as Xbox 360 ones, and iso2god-rs still parses original-Xbox executables (XBE files) alongside Xbox 360 ones (XEX files) when it reads an image. An original-Xbox image in your collection is not an edge case the tools forgot; it is a supported input with its own GOD content type in the package header.

XGD2: the launch-era standard

XGD2 is the Xbox 360’s launch-era disc format and the default mental model for the console’s library: a game mastered into a layout in the roughly 7 GB class, with images padded out to the full mastered size. That padding behaviour is an XGD2-era fact of life that still shapes workflows today — it is why a small game’s ISO still occupies about the full disc size, and why padding removal in Iso2God exists at all. The settings side of that story is in the best padding settings per game.

XGD3: the 2011 step up

XGD3 arrived in 2011 as the format’s mid-generation revision. Contemporary reporting of Microsoft’s own statements put its benefit plainly: it “gives developers an extra 1 gigabyte of data on each disc” — roughly 8.13 GB in total, against the roughly 7 GB class of XGD2. Those figures come from contemporary Microsoft statements reported at the time, not from an official specification sheet, so this page prints them as approximations, which is what they are.

XGD3 reached consoles through a dashboard update, and it also carried new anti-piracy checks — the larger layout was not the only change Microsoft shipped in it. For a modern reader, the anti-piracy context explains why XGD3 generated so much era-specific discussion about drives and burning. That discussion belonged to the disc-burning workflow of the time. It is not part of the ISO-to-GOD workflow: converting an image you already have does not involve a burner, and this page deliberately makes no claims about that separate path.

XSF: the fourth name in the detector

XSF appears in this story in exactly one verified place: the format detection in iso2god-rs, which recognises XGD1, XGD2, XGD3, and XSF images. That is genuinely useful to know if a tool reports your image as XSF — the modern converter accepts it — and it is all our primary sources support. Rather than invent a history for the name, this page leaves it there: detected, accepted, converted.

What the format means for conversion

• Convertibility is not the issue. iso2god-rs reads all four image types and parses both XEX (Xbox 360) and XBE (original Xbox) executables for Title ID and title. The Windows GUI lineage likewise covers Xbox 360 and original-Xbox images.
• Size expectations shift with XGD3. An XGD3 library budgets roughly a gigabyte more per padded game than an XGD2 one. The worked planning examples are in the GOD library storage guide.
• Padding behaviour still applies. XGD3 images are padded layouts too, so the None / Partial / Full decision, and its documented exceptions, apply in the same way.
• The output is the same GOD format. Whatever the input generation, the result is a Games On Demand (SVOD) package: a header plus a .data folder of part files, playable on a modded console or in an emulator. The format comparison with extracted games is in GOD packages versus XEX folders.

What this page does not claim

Precision has limits here, and honesty about them is part of the explainer. Our sources do not support printing exact sector counts or security-sector offsets for these formats, and claims of that kind circulating elsewhere were not verified against a primary source in this session, so they do not appear. Likewise, nothing about special burning hardware belongs in a conversion guide. What is verified — the eras, the approximate sizes, the 2011 arrival and anti-piracy context of XGD3, and the converter’s detection list — is enough to make every decision an Iso2God user actually faces.

The console rule, once more

Disc format does not change playback requirements. A GOD package converted from any of these image types carries an unlocked licence and needs a modded Xbox 360 (JTAG, RGH, or a BadUpdate-class exploit), or an emulator such as Xenia on PC — whose own format support is covered in the Xenia GOD format guide. A stock retail console will not run the result, whatever generation disc it came from.

Frequently asked questions

What is the difference between XGD2 and XGD3?

XGD3 is the 2011 successor to the launch-era XGD2 format. It gave developers roughly an extra gigabyte per disc — about 8.13 GB total versus the roughly 7 GB class of XGD2, both approximate — arrived through a dashboard update, and carried new anti-piracy checks.

Can Iso2God convert XGD3 games?

Yes. The modern converter iso2god-rs detects and accepts XGD1, XGD2, XGD3, and XSF images. For XGD3-specific issues, see the dedicated XGD3 guide linked at the top of this page.

What is XGD1?

The original Xbox’s game disc format, and still a supported input: the Iso2God lineage converts original-Xbox images as well as Xbox 360 ones.

Does an XGD3 game take more storage than an XGD2 game?

At padded disc size, roughly a gigabyte more per game, approximately. After padding removal, a GOD package reflects the game’s actual content, so the gap depends on the game rather than the format label.

More explainers and conversion walkthroughs are collected on the Tutorials hub.

Plan your Xbox 360 game storage space around one contrast: a padded ISO image costs you roughly the full disc size for every game — around the 7 GB class for an XGD2 title, and roughly a gigabyte more for XGD3 — while a padding-removed GOD package costs only what that game actually contains, which varies widely from title to title. Libraries planned on the padded number are always big enough; libraries planned on a guessed GOD average are where people run out of drive mid-transfer.

This guide works the arithmetic honestly. There is no verified per-game GOD size table we can print — no primary source publishes one, and inventing sizes for named games would be fabrication — so every worked example below uses clearly labelled typical planning ranges, stated as assumptions you can adjust, not as measurements of any specific game. Your own games will land somewhere inside these ranges, and the method matters more than any single number.

For the settings that produce the smaller number, start with the best padding settings per game. For the drives themselves, see the buying guide to the best hard drives for an Xbox 360 RGH setup. The converters are on the download page.

Why padded images all cost about the same

A retail disc image is padded to the full mastered layout of the disc. Unused and padding sectors fill the layout whether the game needs them or not, which is why disc images are described as zeroed out to roughly 7 GB no matter how big the game itself is. XGD3, the 2011 disc format, added roughly another gigabyte of usable data — around 8.13 GB total against the roughly 7 GB class of XGD2, figures from contemporary Microsoft statements and therefore approximate, not a spec sheet. The disc formats are explained in XGD2 versus XGD3 explained.

The consequence for storage planning is simple: if you keep games as padded ISOs, or convert them with padding set to None, every game bills you at close to the full disc rate. Twenty games at that rate is a very different drive from twenty padding-removed GOD packages.

Why GOD sizes vary — and why that is the point

Padding removal exists precisely because the padding is not game data. Remove some of it (Partial) or all of it (Full), and the resulting GOD package reflects the game’s real content plus the container’s structure — a header file and a folder of data part files. A small game shrinks dramatically; a game that genuinely filled its disc barely shrinks at all. That variance is real information about the games, and it is why any guide quoting one fixed “average GOD size” as a fact should not be trusted.

There are also documented games where you should not chase the smallest number at all: Tetris – The Grand Master Ace needs Partial rather than Full, and Wolfenstein: The New Order Disc 1 needs its padding kept. A library plan should budget for a few games landing at the large end because the correct setting for them was the conservative one.

Worked example: planning ranges, not per-game claims

The table below is arithmetic, not measurement. It assumes a planning range of 4–6 GB per padding-removed GOD package — a deliberately mid-range assumption for mixed libraries, labelled as an assumption — and compares it with keeping the same library at padded disc size, using approximately 7 GB per XGD2 game. Substitute your own average once you have converted a few of your own games and can see where they land; the totals scale linearly.

Read the ranges as floors with headroom, not as promises. An XGD3-heavy library sits above the XGD2 padded column. A library of genuinely large games sits at the top of the GOD range. And none of these columns includes the other things a working console accumulates: title updates, DLC (which must live under the Content structure), save data, and the free space any drive needs to behave well during large FTP or USB transfers. Add a sensible margin — planning to fill a drive to its last gigabyte is planning to redo the transfer.

A planning method that survives contact with your library

1. Convert a sample first. Convert five to ten of your own games at Partial and note their GOD sizes. That is your real average, for your games, replacing the planning range above.
2. Multiply honestly. Sample average times library size, then add the XGD3 and keep-padding exceptions you already know about.
3. Add the non-game load. Title updates, DLC, saves, and working headroom for transfers.
4. Decide what the ISOs do. Keeping source ISOs as an archive roughly doubles the total storage story; many people archive them on a PC or external drive rather than on the console. The format trade-offs are in GOD packages versus XEX folders.
5. Buy the drive for the number you just computed, using the criteria in the RGH hard drive buying guide — capacities and fit, checked against current listings rather than prices quoted here.

Transfer time is storage planning too

A smaller library is not only cheaper to house; it is faster to build. Every gigabyte padding removal saves is a gigabyte that never crosses your USB connection or FTP session, and GOD packages move as a header plus a bounded set of large part files. When people describe a conversion workflow as “slow”, a padded library being copied in full is very often the actual cause.

Who can play the result

Storage maths does not change the console rule. GOD packages from Iso2God carry an unlocked licence and need a modded Xbox 360 (JTAG, RGH, or a BadUpdate-class exploit) on real hardware, or Xenia on a PC. Size your drive for the modded console or the PC library you actually have.

Frequently asked questions

How big is an Xbox 360 GOD game?

It varies by game, because a padding-removed GOD package reflects the game’s real content. A padded image of the same game costs roughly the full disc size instead — around the 7 GB class for XGD2, roughly a gigabyte more for XGD3, both approximate.

How much storage do I need for 50 Xbox 360 games?

Using this guide’s clearly labelled planning range of 4–6 GB per padding-removed GOD package, about 200–300 GB for the games alone, plus title updates, DLC, and headroom. At padded disc size the same library is about 350 GB before extras.

Why is one of my GOD packages almost as big as its ISO?

Because that game genuinely used most of its disc, or because the correct padding setting for it was a conservative one. Both are documented, normal outcomes — not a failed conversion.

Should I keep the ISO after converting?

Keep it until the GOD package has been tested on the console. After that, keeping ISOs is an archiving decision: valuable as the source for re-conversion, but it roughly doubles the storage you need, so most people archive them off the console.

More library and console guides are collected on the Tutorials hub.

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

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.

Aurora Disc to GOD is the on-console route: the Aurora dashboard for modded Xbox 360 consoles includes a Disc-to-GOD script that converts a game on the console itself, without a PC conversion in between. That makes Aurora the natural counterpart to Iso2God — same destination format, completely different place of work.

Aurora is the current default custom dashboard for modded Xbox 360 consoles in ConsoleMods’ documentation, and the successor-line dashboard to Freestyle Dash (FSD). If you have set up a JTAG or RGH console recently, Aurora is very likely what boots on it. This guide describes what it does with GOD packages, what its disc-to-GOD route is good for, and where a PC conversion with Iso2God is still the better tool. One honesty note up front: we do not print an Aurora version number on this page, because we could not verify an exact latest version from a primary source in this session, and an invented one would help nobody.

The PC side of this workflow — converting, then uploading the finished package to Aurora over FTP — is covered step by step in the Iso2God FTP upload to Aurora guide. The converters themselves are on the download page.

What Aurora is, in one pass

• A custom dashboard for modded Xbox 360 consoles (JTAG, RGH, and BadUpdate-class setups), in the line that follows Freestyle Dash.
• A game scanner and library. Aurora scans GOD packages and extracted games stored anywhere on the console’s storage, not only in the stock Content folder.
• An FTP server. The console can receive files over the network, which is how PC-converted GOD packages are uploaded to it.
• A metadata fetcher. Aurora pulls cover art and title updates (TUs) through XboxUnity.
• A conversion host. Its Disc-to-GOD script converts a game on the console, described below.

That combination is why Aurora sits at the centre of most modern modded-console setups. The dashboard is not just a launcher; it is the library manager, the network endpoint, and — through the script — one of the conversion tools.

The on-console Disc-to-GOD script

The Disc-to-GOD script runs on the console and converts a game disc’s content into a GOD package in place. Its appeal is obvious: the game is already at the console, so there is no ISO to move to a PC, no conversion queue on another machine, and no package to transfer back. For a single game you already own on disc and want on the hard drive, that is the shortest path.

Its limits follow from the same fact. The console is doing the work, so the console’s speed, storage, and your patience set the pace, and you get none of the PC tools’ controls: no per-game padding decision of the kind the Iso2God GUI offers, no queue of many images processed while you do something else, and no command-line repeatability. Treat the script as a convenience for games at the console, not as a replacement for a library-scale PC workflow.

Scanning: GOD packages can live anywhere

One of Aurora’s most useful behaviours is where it looks. On the stock dashboard, a GOD package is only visible if it sits in the Content structure — Content\0000000000000000\<TitleID>\00070000\ on internal or USB storage. In Aurora, a GOD package can live anywhere on disk and be picked up by a scan of that path. That frees you from the stock folder discipline for games launched through Aurora, and it makes external and secondary drives much easier to organise.

Two qualifications keep that freedom honest. First, downloadable content still belongs under Content even when the game itself lives elsewhere. Second, “anywhere” still means “anywhere Aurora is configured to scan” — if a newly copied package does not appear, checking and re-running the scan for that path is the first fix, before suspecting the package.

Covers and title updates through XboxUnity

Aurora fetches cover art and title updates via XboxUnity, which is what turns a scanned folder of packages into a browsable library with artwork, and what keeps games updated without manual file hunting. If covers are missing after a scan, the usual cause is connectivity or the fetch step, not the GOD package itself — a package that launches is a working package whether or not its cover downloaded.

On-console conversion versus Iso2God on PC, compared briefly

The padding row is the one with real consequences. Documented cases such as Tetris – The Grand Master Ace (use Partial) and Wolfenstein: The New Order Disc 1 (keep padding) need a deliberate setting, and that decision lives on the PC side. See the best padding settings per game before converting a game with a known exception, whichever route you take afterwards.

A sensible combined workflow

1. Convert the bulk of a library on PC with Iso2God or iso2god-rs, choosing padding per game.
2. Upload finished packages to Aurora by FTP — the dedicated walkthrough is the FTP upload guide.
3. Scan the destination path in Aurora so the new packages appear in the library.
4. Fetch covers and title updates through XboxUnity once the games are listed.
5. Use the on-console Disc-to-GOD script opportunistically for a single disc that is already at the console, rather than round-tripping it through the PC.

Who this is for — and who it is not

Everything on this page assumes a modded console. Aurora itself only runs on a modified Xbox 360, and GOD packages produced by Iso2God carry an unlocked licence that a stock retail console refuses. There is no Aurora route for an unmodified console, and any page suggesting otherwise is misleading you. On a PC, the equivalent playback route for GOD packages is an emulator, covered in the Xenia GOD format guide.

Frequently asked questions

What is Aurora on Xbox 360?

Aurora is a custom dashboard for modded Xbox 360 consoles, the current default in ConsoleMods’ documentation and the successor-line to Freestyle Dash. It scans and launches games, serves FTP, fetches covers and title updates via XboxUnity, and hosts a Disc-to-GOD script.

Can Aurora convert a game disc to GOD?

Yes. Aurora includes an on-console Disc-to-GOD script that converts a game on the console itself, with no PC conversion step and no transfer afterwards.

Where do GOD packages have to be for Aurora to see them?

Anywhere on the console’s storage that Aurora is set to scan. Unlike the stock dashboard, Aurora is not limited to the Content\0000000000000000\<TitleID>\00070000\ path — though DLC still belongs under Content.

Should I convert on the console or on a PC?

On the console for a single disc that is already there; on a PC for a library, for repeatability, and for any game where the padding setting matters. The two routes produce the same kind of package and combine well.

More console-side and conversion guides are collected on the Tutorials hub.

The current answer to the Xenia GOD format question is simpler than most guides suggest: current Xenia Canary loads GOD packages directly, alongside ISO images and extracted default.xex folders. You no longer have to convert every GOD package back to an ISO before the emulator will touch it — although that older route still exists, and in some situations it is still the useful one.

Xenia is a research emulator for the Xbox 360, not a finished commercial product, and it is actively maintained: the Xenia Canary repository was still receiving pushes on 23 October 2026, the day this guide was checked. That maintenance pace is exactly why older advice goes stale. A guide written when Canary could not open a GOD package will confidently send you through a conversion step that current builds have made optional.

This page presents both routes, dated, so you can tell which one your build needs. For the reverse conversion itself, see converting GOD to ISO with God2Iso. The tools are linked from the download page.

What Xenia Canary accepts today

That list is the reason the GOD question keeps changing. GOD is a Secure Virtual Optical Disc (SVOD) container: a header file plus a folder of data part files. An emulator that understands that container can open the package as it stands. An emulator build that only understands disc images cannot, and needs the package rebuilt into an ISO first.

How to open a GOD package in Xenia Canary, step by step

1. Use a current Xenia Canary build. The direct-GOD behaviour described here is the current behaviour; an old build is the most likely reason it will not work.
2. Keep the GOD package complete. A GOD conversion produces a header file and a matching .data folder of part files (Data0000, Data0001, and so on). Moving or copying only the header leaves the emulator with nothing to read.
3. Open the package from the emulator’s file dialog and select the GOD header file for the game.
4. If the build refuses the package, fall back to the dated route below rather than re-converting the game from scratch. Your GOD package is probably fine; your emulator build is probably old.

Keep that completeness point in mind when you tidy a library. Deleting a .data folder because it “looks like leftovers” deletes the game. The structure is explained in depth in GOD packages versus XEX folders.

The older route, dated: GOD first, then God2Iso, then Xenia

Older Xenia guides, and plenty of forum answers copied from them, give a three-step chain: take the GOD package, run it through God2Iso to rebuild an ISO, and open that ISO in the emulator. God2Iso (raburton/god2iso) does exactly that one job — GOD to ISO — and its last release, v1.0.5, is from 19 April 2023, when it became open source under CC BY-SA 4.0.

That route was correct for the emulator builds those guides were written against. It is not wrong today; it is just no longer the mandatory first step for a current Canary build. Presenting both matters because readers arrive with both kinds of build installed, and because a page that silently deletes the old route leaves those readers with a package their emulator genuinely cannot open and no explanation.

When converting GOD to ISO still helps

• Your emulator build does not accept GOD packages. Older builds, and builds other than current Canary, may still need an ISO. God2Iso is the standard rebuild tool for that case.
• Another tool in your chain only accepts ISO. Extractors, inspection tools, and older utilities were often written against disc images only. Rebuilding an ISO gives them something they understand.
• You want to extract the game’s files. An ISO is the practical intermediate step toward an extracted folder, and extracted default.xex folders are themselves a format current Canary opens.
• You are archiving in one format. If your whole library standard is ISO images, converting a stray GOD package keeps the archive uniform — a housekeeping choice, not a compatibility requirement.

The full reverse workflow, including the verified God2Iso download, is in the God2Iso guide. Note the direction carefully: Iso2God and iso2god-rs convert ISO to GOD. God2Iso converts GOD back to ISO. They are different tools doing opposite jobs, and iso2god-rs has no GOD-to-ISO mode.

GOD on a PC versus GOD on a console

Do not confuse the two playback routes for the same package. On a PC, Xenia is the route, and no console is involved. On real hardware, a GOD package produced by Iso2God carries an unlocked licence and requires a modded Xbox 360 — JTAG, RGH, or a BadUpdate-class exploit. A stock retail console will not run it, and no emulator setting changes that. Choose the route first, then follow the instructions for that route.

If your goal is the console rather than the emulator, read how the Aurora dashboard handles GOD packages and keep your padding choices conservative using the per-game padding guide.

Troubleshooting a GOD package that will not open

1. Check the build date first. Update to a current Canary build before suspecting the package.
2. Check the package is complete. Header file present, matching .data folder present, part files inside it.
3. Try the ISO route as a diagnostic. Rebuild an ISO with God2Iso and open that. If the ISO opens, the game data is intact and the problem was format support in your build.
4. Re-convert from the source ISO only as a last resort, at Partial padding, using a tool from the download page.

Builds and platforms to know about

Xenia’s main project is Windows-first. Xenia Canary, the experimental build line most guides mean when they say “Xenia” today, also ships a Linux AppImage alongside its Windows archive, which is why current GOD support should be judged on a Canary build rather than on an old master-branch snapshot. The master Xenia project and Canary are related but separate repositories with separate release rhythms; a limitation you read about in one is not automatically a limitation of the other. When a guide does not say which build it tested, treat its format claims as undated — which, for GOD support, usually means out of date.

Frequently asked questions

Can Xenia play GOD files?

Current Xenia Canary can load GOD packages directly, as well as ISO images and extracted default.xex folders. Older builds may need the package rebuilt into an ISO with God2Iso first.

Is Xenia still maintained?

Yes. Xenia describes itself as a research project, and the Canary repository was receiving pushes on 23 October 2026. Expect a research emulator’s rough edges, not a finished product’s polish.

Do I need God2Iso if I use Xenia?

Not with a current Canary build and a complete GOD package. Keep God2Iso for older builds, for tools that only accept ISO images, and for getting from a GOD package toward extracted files.

Can I convert a GOD package with iso2god-rs instead?

No. iso2god-rs converts ISO to GOD only. It has no GOD-to-ISO mode and does not take XEX-folder input. The reverse direction is God2Iso’s job.

More guides are collected on the Tutorials hub.

The best padding settings per game in Iso2God start from one safe rule: use Partial as your default. Switch to Full only when saving space matters most and that specific game is known to tolerate it, and keep padding (None) for installer discs and any game where removal has been documented to break the conversion.

Padding is not game data. A retail Xbox 360 disc image is padded to the full mastered layout, so an ISO of a small game still occupies roughly the full disc size. Removing that padding makes the resulting Games On Demand (GOD) package smaller, faster to copy over FTP or USB, and cheaper to store. The trade-off is compatibility: a small number of games genuinely depend on parts of that layout, and for those games aggressive removal produces a package that installs, or appears to install, and then fails.

This guide gives you a decision for each situation rather than a single universal setting. For the underlying mechanics first, read how Iso2God padding works, explained in full. If a conversion already went wrong, go straight to what to do when padding broke your game. Every tool mentioned here is on the download page.

The three modes, in one table

None of these modes changes the game itself. They change how much of the empty, mastered layout travels with it. That is why the same game can work perfectly with one setting and fail with another: the difference is layout, not content.

Default: Partial, and why it earns that spot

Partial removes enough padding to deliver most of the storage and transfer benefit while staying conservative about the layout. In practice that means you should not need a reason to choose Partial — you need a reason to choose anything else. Start every unfamiliar game at Partial, convert, transfer, and test it on your console before you delete the source ISO.

That testing step matters more than the setting itself. Keep the original ISO until the GOD package has actually launched and played past its opening section on your modded console. A conversion log that finishes cleanly tells you the package was written; it does not tell you the game tolerates the layout you chose.

Documented case 1: Tetris – The Grand Master Ace needs Partial

The clearest documented counter-example to “always use Full” is Tetris – The Grand Master Ace. The r4dius fork maintainer’s own per-game compatibility notes record that this game breaks when padding is set to remove all of it, and that Partial is the setting to use. This is not a rumour repeated between forums: it is written in the README of the maintained Windows GUI fork.

Treat that one case as a warning about the whole category. If a game this simple can depend on its padded layout, you cannot assume an unfamiliar game is safe with Full just because most games are. When in doubt, Partial is the documented, defensible answer.

Documented case 2: Wolfenstein: The New Order Disc 1 keeps its padding

Wolfenstein: The New Order Disc 1 is the opposite exception. ConsoleMods’ documentation records that this disc’s installer requires its padding to be left intact for its first GOD conversion. In Iso2God terms that means None — do not trim this disc down on the first pass.

The reason is the disc’s job. Disc 1 here is an installer, not simply the first half of the game. Installers read and copy content in ways that can depend on the original layout, which is exactly the situation padding removal disturbs. Once content is installed by the route the documentation describes, later discs are a separate question — judge each disc on its own role, not on the game’s name.

The two-disc pattern: install disc versus play disc

Many two-disc Xbox 360 releases split their content into an install disc and a play disc, and they should not be converted as if they were two equal halves. The r4dius README’s own per-game table documents the common pattern for many two-disc games, including titles such as Grand Theft Auto V and Battlefield 4: Disc 1 is handled as extracted install content, and Disc 2 becomes the GOD package.

Before converting any multi-disc game, check which disc installs and which disc plays. Queuing both discs through identical settings is the single most common way to create a package set that looks complete and does not work. The Iso2God GUI queues discs one by one for a reason: each disc gets its own decision.

When Full is the right choice

Full has a legitimate use. Choose it when all of the following are true: the game is a single play disc rather than an installer, storage or transfer time is a real constraint for you, nothing documents a padding problem for that title, and you will test the result before deleting the ISO. Full is also the mode behind the GUI’s rebuilt-ISO workflow, where an ISO is rebuilt with full padding removed to produce a smaller image rather than a GOD package.

Space is the honest reason to reach for Full. If that is your situation, pair this guide with how much storage a GOD library actually needs and GOD packages versus extracted XEX folders — sometimes the format choice saves more space and trouble than the padding choice.

A note on iso2god-rs and –trim

If you convert with the command-line tool iso2god-rs instead of the Windows GUI, do not map its option onto these three modes. The --trim option in iso2god-rs only drops unallocated space from the end of the image. That is narrower than Partial and much narrower than Full, and it is not the same feature, even though the effect overlaps for many games. A game that needs Partial in the GUI is not automatically handled by --trim, and a game that breaks with Full may be fine with --trim for a different reason. Both tools are linked from the download page.

Step by step: choosing a setting for a new game

1. Identify the disc’s role. Single play disc, install disc, or play disc from a multi-disc set?
2. Check for a documented exception. Tetris – The Grand Master Ace means Partial; Wolfenstein: The New Order Disc 1 means keep padding.
3. Start at Partial for everything else, unless storage pressure is severe.
4. If you chose Full, test before you trust it. Launch the game and play past the opening on the console.
5. Keep the source ISO until that test passes. Re-converting is cheap; re-ripping is not.

Who can play the result

Padding choices do not change the console requirement. A GOD package produced by Iso2God carries an unlocked licence, so playing it requires a modded Xbox 360 — JTAG, RGH, or a BadUpdate-class exploit — or an emulator such as Xenia. A stock retail console will refuse it regardless of whether you chose None, Partial, or Full. This site is an unofficial fan resource and states that plainly on every guide.

Frequently asked questions

What is the best padding setting for most games?

Partial. It is the safe default in the GUI workflow: it removes some padding, saves real space, and avoids the documented failures that come with removing all of it.

Is Full ever safe?

Yes, for many single-disc games, and it saves the most space. It is not universally safe, which is why it should be a deliberate choice with a test afterwards, not a global default.

My game broke after I removed all the padding. What now?

Re-convert from the original ISO at Partial, and for an installer disc keep the padding entirely. The full recovery walkthrough is in the padding-broke-my-game guide.

Does iso2god-rs have Partial and Full modes?

No. iso2god-rs offers --trim, which only removes unallocated space from the end of the image. It is a command-line tool with a different, narrower option, described on the download page.

More conversion walkthroughs live on the Tutorials hub. Next, see XGD2 versus XGD3 explained if you are unsure what kind of disc image you are starting from.