Unity Asset & APK Decompiler Online

For editor exports with GUID directories, use the Unity package extractor to restore supplied Assets/ paths and .meta files.

Standalone Unity Assets and Bundles

Upload .unity3d, .assets, .assetbundle or Unity .bundle files directly. Container headers are validated, so renamed valid files work too. A .bundle suffix alone does not mean Unity: React Native Hermes bundles use a different extractor.

For streamed textures and audio, ZIP the container together with its sibling .resS and .resource files, keeping their names and folder structure. Missing companions leave the available exports and serialized data intact; DECOMPILATION-NOTES.txt and the report explain which resource is absent. Unrelated ZIP files are not imported.

Standalone output is grouped under unity/textures/, unity/audio/, unity/meshes/, unity/text/ and other asset categories. unity/_report.json lists engine versions, object counts, export counts and individual failures. These containers hold assets and metadata; they do not supply C# method bodies or an editable Unity project.

A Unity APK Is Two Applications in One

An ordinary APK decompiler reads Dalvik bytecode and Android resources. In a Unity game that gets you the launcher activity, the ad and analytics SDKs, and a class called UnityPlayerActivity — and nothing whatsoever of the game. The game lives in a second payload the Android toolchain never touches: serialized Unity assets under assets/bin/Data/, and script code in either managed .NET assemblies or a native IL2CPP binary.

Upload an APK here and both halves are handled. You still get the usual sources/, resources/ and smali/ folders; a detected Unity build adds a unity/ folder next to them.

What Ends Up in an APK's unity/ Folder

• unity/README.txt — detected backend, target architectures, and a per-stage report of what succeeded, what did not, and why.
• unity/assets/ — exported game content sorted by kind: textures/ and sprites/ as PNG, audio/ as decoded samples, meshes/ as OBJ, fonts/ as TTF or OTF, shaders/ and text/ as text, video/ in its original container, and serialized-behaviours/ holding MonoBehaviour data.
• unity/assets/script-types.json — every MonoScript the build references: assembly, namespace and class name. This is the map from serialized behaviours to the code that reads them.
• unity/assets/_report.json — the Unity engine versions found, a census of object types, per-category export counts, and each object that failed with its error.
• unity/scripts/csharp/ — C# files produced by ILSpy. Real code for Mono builds; type stubs for IL2CPP.
• unity/scripts/managed-assemblies/ (Mono) — the managed DLLs lifted straight out of the APK, including Assembly-CSharp.dll.
• unity/scripts/il2cpp/ (IL2CPP) — dump.cs, the generated DummyDll/ assemblies, and the dumper's script and string-literal maps.

Mono vs. IL2CPP: What You Can Actually Recover

This is the single question that decides how much of a Unity game you get back, and it was settled by whoever built the game, years before you downloaded it.

Mono builds ship C# compiled to .NET IL in Assembly-CSharp.dll. IL keeps the full type system and the instruction stream maps cleanly back to C#, so decompilation returns method bodies, control flow, string constants and usually field and parameter names. This is the good case: the output reads like source. Mono was Unity's original backend and is still used by plenty of Android games, especially smaller ones and older builds.

IL2CPP builds converted that same IL to C++ and then to native ARM machine code, shipped as libil2cpp.so. The C# method bodies do not exist in the APK in any form a decompiler can read — they are compiled machine instructions. What does survive is global-metadata.dat, the file the runtime uses to reflect over its own types, and it is remarkably informative: class and struct declarations, inheritance, field types, method signatures, attributes, every string literal in the program, and the native address of each method body. Il2CppDumper turns that into dump.cs and a set of dummy assemblies, which ILSpy then renders as browsable C# stubs.

So on an IL2CPP game you can see the entire architecture of the code — every class, every method name, every constant string, and where each method lives in the binary — but not the statements inside the methods. Recovering those means reading the native code at the addresses in the dump with a disassembler.

Why Unity Assets Need a Different Extractor

Unity does not ship PNG or WAV files. At build time everything is packed into serialized files — data.unity3d, globalgamemanagers, level* and asset bundles — where each object is a binary record laid out according to a type tree that is itself embedded in the file, and textures are stored in GPU-native compressed formats such as ETC2, ASTC or DXT rather than any format an image viewer knows. Reading them means implementing Unity's serialization format and its texture codecs. That is what runs here, per object, so that one unreadable asset costs you that asset and nothing else.

Objects that cannot be parsed are still written out as raw bytes under assets/unparsed/, and MonoBehaviour records are always saved as raw .bin alongside a JSON type tree when one can be read — IL2CPP builds frequently lack the type information needed to deserialize custom behaviour fields, and the raw bytes remain useful.

Limits

• Container limits. Up to 512 MiB per container or companion, 2 GiB of extracted ZIP inputs and asset output, 20,000 ZIP entries or exported asset files, and 32 folder levels. Extraction also shares the upload job's time and output budget. Available results remain browsable when a limit is reached.
• Formats. UnityFS and legacy UnityRaw/UnityWeb bundles, and serialized asset headers from revisions 9 through 22 are recognized. Export compatibility varies by engine version and object type; encrypted bundles, split files and Unity WebGL data packages are not supported by this standalone path.
• No original project. Scenes, prefabs, the asset database and the C# project layout are build artefacts of the editor, not of the shipped game. Nothing recreates them.
• Encrypted or custom-packed games. Studios that encrypt global-metadata.dat, obfuscate the metadata header or pack assets behind a custom loader defeat off-the-shelf extraction. The report will say so rather than pretending otherwise.
• Downloaded content is absent. Anything fetched at runtime — addressables, remote bundles, live-ops content — was never in the APK.
• Obfuscated names stay obfuscated. If the build ran an obfuscator, class and method names come back as the obfuscator left them.
• Size and time caps. Each analysis stage is time-limited and asset export stops at 20,000 files, so a pathological game cannot monopolise a worker. Partial output is kept and the truncation is recorded in _report.json.

What It Is Used For

Recovering your own game's content after losing the project, auditing an SDK a game embeds, checking whether a shipped build leaks API keys in its string literals, investigating asset theft, modding and translation work, and studying how a technique was implemented. Decompiling software you do not own may be restricted by its licence and by local law; that is your call to make before you upload.

Frequently Asked Questions