Unity APK Decompiler Online

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 the 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

• 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