Save / Load Systems in Godot 4.3+

Choose the right serialization strategy for your data type. All examples target Godot 4.3+ with no deprecated APIs.

Related skills: resource-pattern for custom Resource data containers, inventory-system for inventory serialization patterns, godot-project-setup for SaveManager autoload setup, popochiu for adventure-framework saves.

1. Strategy Comparison

Security warning: Loading .tres or .res files executes arbitrary GDScript embedded in the resource. Never load Resource files from untrusted sources (user-uploaded files, downloaded mods). Use ConfigFile or JSON for user-generated save data.

2. ConfigFile — Settings

ConfigFile writes INI-style sections — ideal for audio / video / controls settings (small, designer-debuggable). Use setvalue(section, key, value) then save(path); load with load(path) and getvalue(section, key, default).

See [references/configfile.md](references/configfile.md) for the full GDScript + C# settings save/load + typical settings-menu wiring.

3. JSON — Game Saves

JSON.stringify(dict) to serialize, JSON.parsestring(text) to deserialize. Read/write through FileAccess. Best for game saves where you want human-readable files. Build a Dictionary that captures all gameplay state (player position, inventory, world flags), serialize, write to user://save<slot>.json.

See [references/json-saves.md](references/json-saves.md) for the full GDScript + C# save/load implementation, including FileAccess wrapping and error handling.

⚠️ Changed in Godot 4.7: JSON.stringify(data, indent = "", sortkeys = true, fullprecision = false) now serializes an empty Dictionary compactly as {} even when an indent is passed (GH-115883). Save files written with an indent change formatting for empty-dict fields after upgrading — anything that diffs or hashes save output byte-for-byte must tolerate the new form. Parsing is unaffected.

4. Save Architecture Pattern

For larger games, attach a SaveableComponent to each persistent node. Each component declares savecallable and loadcallable. The save manager iterates components by ID, calls each one's save callable, builds a master Dictionary.

See [references/save-architecture.md](references/save-architecture.md) for the full SaveableComponent + save-manager implementation.

5. Save File Locations

user:// resolves to a platform-specific writable directory outside the project folder.

Always use user:// for save data, never res://. The res:// path is read-only in exported builds.

6. Version Migration

Save files outlive the schema that wrote them. Always include "version": <int> at the top of the saved Dictionary; on load, switch on the version and migrate older saves forward incrementally (v1 → v2 → v3 → current). Never break old saves — always migrate.

See [references/version-migration.md](references/version-migration.md) for the full migration helper pattern.

7. Implementation Checklist

• Use ConfigFile for settings, JSON for game saves (not Resources)
• Every save file includes a version integer field
• Save path uses user://, never res://
• Call DirAccess.makedirrecursive_absolute() before writing saves
• Vector2/Vector3 serialized as separate x/y/z floats (JSON has no Vector type)
• All file operations check return codes and call push_error() on failure
• _migrate() handles every version from 0 to current, applied incrementally
• Resource files (.tres/.res) are never used for player-controlled save data
• getsaveslots() and delete_save() helpers exist for UI slot management
• Saveable nodes use stable IDs that do not change between sessions