Serialization in Unity Explained: The Secret Behind How Your Data Survives

You’ve probably experienced this: you hit Play, tweak a few values in the Inspector, stop the game—and poof! Everything’s back to the way it was. Or maybe you changed a private variable, re-opened the project, and your edits mysteriously disappeared.

Welcome to the world of serialization—one of Unity’s least visible but most fundamental systems.

Serialization is how Unity remembers what your game objects look like, how your prefabs hold onto their settings, how ScriptableObjects persist, and even how AssetBundles ship data to your players. Let’s peel back the layers and see what’s actually happening.

What Is Serialization?

Serialization is the process of converting objects in memory into a format that can be stored or transmitted—and later reconstructed.

In Unity’s case, it means turning all your GameObjects, Components, and variables into data on disk (usually YAML text while editing, binary at runtime).

When you save a scene, Unity walks through your hierarchy, finds all serializable fields, and writes them into the scene file.
When you open that scene again, Unity deserializes those values, rebuilding your GameObjects exactly as you left them.

Why Unity Uses Serialization

Serialization isn’t optional in Unity—it’s the backbone of the Editor experience.
It exists to solve three fundamental problems:

1. Persistence across sessions
   Unity must save and reload all your object data whenever you close and reopen the project.

2. Inspector editing
   When you expose variables in the Inspector, Unity needs somewhere to store your edits.
   The Inspector doesn’t show live memory—it shows serialized data.

3. Reconstructing prefabs, scenes, and builds
   Every prefab and scene is a serialized container.
   That’s how you can duplicate prefabs, undo changes, or load assets dynamically at runtime.

Without serialization, every scene save, prefab creation, or asset reference would collapse the moment you quit Unity.

How Unity’s Serialization System Works

Unity’s serialization is not the same as .NET’s BinaryFormatter or JSON serialization.
It’s a custom C++ system tailored to Unity’s object model.
Here’s what it handles:

• Scenes and prefabs (.unity, .prefab)

• ScriptableObjects

• MonoBehaviours (fields on GameObjects)

• Built-in UnityEngine objects (materials, textures, audio clips)

What Gets Serialized

Unity serializes:

• All public fields of supported types

• All private or protected fields marked [SerializeField]

• Supported types include primitives, strings, Unity structs (Vector3, Color), arrays, and Lists

• Custom classes marked [System.Serializable]

What Doesn’t Get Serialized

Unity skips:

• Properties

• Dictionaries

• Interfaces or abstract classes

• Types without [System.Serializable]

• References to unmanaged resources (file handles, sockets, etc.)

One Example That Explains Everything

Let’s use a clean, realistic example that shows what actually happens across Play Mode and Editor sessions.

public ints get serialized by default

Step 1: Before Play Mode (Editing in the Inspector)

• You can see health in the Inspector.

• runtimeCounter is private, so it’s hidden.

• Change health to 75 and save the scene.

Unity writes that value (75) into the scene file—it’s now serialized.

Step 2: Enter Play Mode

• Unity loads a copy of your scene into memory.

• It deserializes health = 75 from disk and constructs your object.

• The game runs. Maybe you reduce health to 60 and increment runtimeCounter.

• Both values exist only in memory.

Step 3: Stop Play Mode

• Unity destroys the runtime copy and reloads the serialized version from disk.

• health jumps back to 75 (the serialized value).

• runtimeCounter resets to 0 (default code initialization).

Step 4: Close and Reopen Unity

• The Editor reads the serialized scene file.

• health again restores to 75.

• runtimeCounter starts from 0, since it was never serialized.

Summary of how data is processed

🧭 Key idea:
Serialized fields revert to their last saved values.
Non-serialized fields revert to their default code values.
Both reset after Play Mode—but for very different reasons.

Editor vs Play Mode in One Sentence

Unity serializes when you save, not while you run. Play Mode runs temporary copies in memory. When it stops, Unity reloads from disk.

The Role of [System.Serializable]

Many devs assume that if a field is public, Unity will automatically save its contents—including nested classes.
That’s not true for custom classes.

Incorrect Version

The Weapon class here is NOT serialized

Even though Weapon is public, Unity will skip it. You’ll see the field in the Inspector, but it won’t expand—and Unity won’t remember any of its data.

Correct Version

Note the attribute added to the Weapon class

Now Unity knows it should traverse the Weapon fields and serialize them too.

How to make fields and classes serializable

The public keyword isn’t enough to serialize a class

ScriptableObjects and Serialization

ScriptableObjects exist solely because of serialization. They’re serialized .asset files that persist data outside of any scene.

ScriptableObjects are serialized

How Each Field Is Serialized

Note that the object is serialized as a reference

Why the Sprite Gets Serialized

Sprite inherits from UnityEngine.Object. Unity serializes such fields as references, not as raw data. The .asset file stores the Sprite’s GUID and fileID, not the image bytes.

That’s why:

• If you move or delete the Sprite, you’ll see “Missing (Sprite)” in the Inspector.

• Duplicating the ScriptableObject doesn’t duplicate the texture—it still points to the same Sprite.

How Unity Serializes Asset References

If you open an asset file in a text editor, you’ll find something like:

Unity uses this to reconnect asset references automatically when deserializing scenes or prefabs.

Serialization Beyond the Editor: AssetBundles and Runtime Loading

Serialization isn’t just for saving scenes—it’s also how Unity ships assets to players.

When you build an AssetBundle, Unity:

1. Collects the chosen assets.

2. Serializes them into a compact binary format.

3. Saves that bundle to disk.

At runtime, when you call:

Unity deserializes those assets back into memory, reconstructing every component and reference.

That’s why bundles built in Unity 2022 may not load in Unity 2025—the serialization schema changes between versions.

Why Unity Uses This

• Efficient data transfer over networks (you can host bundles on a CDN).

• Exact preservation of asset relationships.

• Cross-platform consistency (same serialized data, different hardware).

So even outside the Editor, serialization powers the entire content-loading pipeline.

Common Serialization Pitfalls

And how to fix them

Behind the Scenes

Open a scene file (.unity) and you’ll find YAML like:

Each section is a serialized object, identified by type (!u!1 = GameObject) and file ID.

When you hit Play, Unity parses this text and builds real C++/C# objects from it. When you hit Save, Unity walks the object tree and rewrites this YAML.

Quick Reference Summary

tldr;

In Short

Serialization is the invisible backbone of Unity. It’s why your data survives project reloads, why prefabs remember their tweaks, and why AssetBundles load the same assets on devices around the world.

Understanding it gives you real power:

• You’ll know exactly why your variables “reset.”

• You’ll structure data correctly (ScriptableObjects, not magic statics).

• You’ll avoid painful “why did Unity forget my value?” bugs.

Once you truly grasp serialization, you stop fighting Unity—and start using it the way the engine was designed.