Scripts in a folder named Editor add authoring features to the Unity Editor and are not available in Player builds at runtime, according to Unity's documentation. Code elsewhere, including the Plugins folder, can ship. Sorting a new asset's code into these two buckets tells you where to look for risk.
Why the split matters
Two different questions come up when you add an asset:
- What can this code do on my developers' machines while we work?
- What does this code do inside the game my players run?
Editor code answers the first. Runtime code answers the second. They need different reviews, and mixing them up either wastes time or misses a real exposure.
What Unity says about the special folders
Unity reserves some folder names under Assets. The manual's table says:
| Folder | Purpose per Unity | Ships in the Player build? |
|---|---|---|
| Editor | Editor scripts that add functionality at authoring time | Not available at runtime in Player builds |
| Editor Default Resources | Assets Editor scripts load on demand | Editor use |
| Gizmos | Images for drawing icons in the Scene view | Editor use |
| Resources | Assets loaded on demand from a script at runtime | Yes; the manual notes they increase build size |
| Plugins | Third-party plugins | Platform specific handling applies |
| StreamingAssets | Files available in original format at runtime | Yes |
The manual also notes an alternative to an Editor folder: create an assembly definition asset for Editor code. So a script outside an Editor folder can still be editor-only if an assembly definition says so. Folder names alone are not the whole answer.
How to sort an asset in ten minutes
- Unzip or import the asset into a scratch project, not your main one.
- List every folder named Editor, and every assembly definition file. Open each assembly definition and note whether it is limited to the Editor platform.
- Everything left over is probably runtime code. List the folders.
- List anything in Plugins. Native libraries and precompiled managed assemblies there are binary and cannot be read like source. See the native plugin inventory guide.
- Check Resources and StreamingAssets for files that scripts load by name. Data that your code interprets deserves a glance.
- Write two short notes: "runs on developer machines" and "ships to players", each with the findings.
What to look for in each bucket
Editor bucket. Code that runs when the editor loads or when a menu item is used can do what any program you run can do. Look for network calls, file writes outside the project, process launching and anything that downloads more code. Our post on opening a downloaded Unity project goes deeper.
Runtime bucket. Look at permissions it needs on mobile, network endpoints it contacts, data it collects, and its libraries. This is what your privacy statements and store forms must reflect.
A common mistake
Teams often review only the scripts they can read, and skip the binaries. A precompiled plugin in the Plugins folder is the code you cannot inspect by eye, so it needs provenance checks instead: who published it, which version, what hash.
Safeguard's SBOM and dependency scanning covers declared packages and libraries in your repository, and you can try a free scan at gold.safeguard.sh/scan. Reading an asset's folders as above is a manual step that complements it.
Quick check
Is code in an Editor folder part of my shipped game?
Unity's manual says Editor scripts are not available in Player builds at runtime. They can still run on developer machines.
Can editor-only code live outside an Editor folder?
Yes. Unity describes assembly definition assets as an alternative way to mark Editor code.
Where do native libraries go?
The manual reserves the Plugins folder for third-party plugins, and platform specific rules apply to its contents.
Sources
Last reviewed: 19 October 2026.
