Godot Decompiler Online

Godot Is the One Engine That Decompiles Properly

Most of what this site does is lossy. C# and Java decompile well because their bytecode keeps a type system; C++ compiled to native code barely decompiles at all; a Unity IL2CPP build gives you declarations and nothing inside the methods. Godot is the outlier in the other direction.

GDScript is never compiled to machine code. Exporting a project turns each .gd file into a .gdc, which is a token stream: the same script with each keyword, operator and identifier replaced by a number, plus tables of the constants and names it used. Nothing is inlined, nothing is optimised away, nothing is renamed. Reversing it is close to running the tokenizer backwards, and what comes out is source — variable names, type hints, signal declarations, enum members, exported properties and the original control flow, all intact.

The one thing that genuinely does not survive is anything the tokenizer threw away: comments, blank lines and the exact spacing. Everything else you get back is what the developer wrote.

What You Upload

• game.pck — the package archive holding the whole game. This is the best thing to upload and the most common file to have.
• game.exe — works when the developer ticked the option to embed the pack. Otherwise the executable is just the engine; see below.
• An Android .apk — recovered alongside the usual Java and smali output.
• A single .gdc — one compiled script, decompiled on its own to a .gd.
• Linux and macOS builds — a binary with an embedded pack is detected the same way, whatever its extension.

The .exe That Contains Nothing

This trips up almost everyone. Godot's Embed PCK export setting is off by default, so the typical shipped game is a folder with game.exe and game.pck side by side. The executable is an unmodified copy of Godot's export template — the same bytes for every game built with that engine version — and contains no part of the game whatsoever.

If you upload one of those, you will get a note saying exactly that. Upload the .pck that sits next to it instead. When the pack is embedded, it is appended to the end of the file with its size and a GDPC marker in the last twelve bytes, which is how it is detected here regardless of what the file is called.

What You Get Back

• project/ — the recovered project: project.godot, scenes as .tscn, resources as .tres, imported assets converted back to PNG, OGG, TTF and the rest, plugin configuration recreated, and every script as .gd. This is a directory the Godot editor can open.
• scripts/ — a flat copy of just the decompiled .gd files, keeping their folder structure. A mid-sized game recovers to a couple of thousand files, most of them art; this is the shortcut to the code.
• gdre.log and project/gdre_export.log — the recovery report: which engine version built the game, what converted cleanly, and anything that did not.
• godot/ — on an APK, the two folders above live here, next to the sources/, resources/ and smali/ that the APK decompiler produces for the Android wrapper.

The recovery report names the editor version to open the project with. Use it: a project recovered from a 3.5 game will not load cleanly in Godot 4.

A Godot APK Is Two Applications in One

Decompiling a Godot Android game with a plain APK tool gets you GodotApp, GodotEditText, a handful of plugin shims and whatever ad SDK was linked in. That is the launcher, not the game.

The game is unpacked loose under assets/ — .gdc scripts, .scn scenes and .ctex textures as individual entries in the APK's zip — along with assets/project.binary, the compiled project settings. Android tooling has no reason to look there, so it never does. Upload the APK here and that half is recovered into godot/ while the Java side is decompiled as normal.

Versions and Formats

Godot 2.x, 3.x and 4.x are all supported, including the pack format introduced in recent 4.x releases that moved the archive's file index to the end of the file.

One quirk is worth knowing. Godot 4.0 through 4.2 shipped GDScript as plain text — the exported pack contains readable .gd files and no bytecode at all. Binary tokenization returned as an export option in 4.3, and games built with 4.3 and later are back to shipping .gdc. Either way you end up with source; in the first case there was never anything to decompile.

Limits

• Comments are gone. They are discarded at tokenization and are not in the file to recover.
• C# projects. Godot's Mono/.NET builds compile C# to a managed assembly shipped beside the pack. The pack still recovers; for the code, upload that .dll to the DLL decompiler.
• GDExtension and GDNative. Native plugins are compiled shared libraries, not bytecode, and do not decompile.
• Encrypted packs. Godot can encrypt a PCK with a 256-bit key set at export. The key is not in the archive, so an encrypted pack cannot be opened, and you will get a note saying so rather than a silent empty result.
• Downloaded content is absent. Anything the game fetches at runtime was never in the file you uploaded.
• A few resource types stay unconverted. Godot 2.x models and some exotic imported formats are extracted as-is rather than converted back; the report lists them.

What It Is Used For

Recovering your own game after losing the project folder — the most common reason by far, and the case Godot's design makes genuinely possible. Beyond that: studying how a mechanic was implemented, auditing what a game does with your data, translation and modding work, and checking whether a shipped build leaks keys in its string constants. Decompiling software you do not own may be restricted by its licence and by local law; that judgement is yours to make before you upload.

Frequently Asked Questions