Unity Build Size Analyser
Drop in your Editor.log to see what is filling your build, and model what removing it would save. Runs entirely in your browser.
Drop your Editor.log here
or LastBuild.buildreport, which gives exact sizes and real asset types
Runs in your browser. Nothing is uploaded.
Where to find Editor.log
| Operating system | Path |
|---|---|
| Windows | %LOCALAPPDATA%\Unity\Editor\Editor.log |
| macOS | ~/Library/Logs/Unity/Editor.log |
| Linux | ~/.config/unity3d/Editor.log |
Unity writes the build report when a player build finishes, so build the project at least once before exporting the log. Unity also truncates Editor.log when the Editor restarts, so copy it before reopening the project.
For more accurate results, use the build report instead
Your project also contains Library/LastBuild.buildreport, written by the same build. It holds exact byte counts and the real Unity type of every asset, where the log rounds to one decimal place and only offers a file path. On a real project the log listed 4,606 entries and the build report listed 9,002. Drop either one in.
What this reads
Unity writes a build report to Editor.log every time you build a player, listing every asset that went into the build and how much space it took. It is genuinely useful and almost nobody reads it, because it is thousands of lines buried in a log file. This tool reads that report and turns it into a breakdown you can sort, filter and model against, so you can see what to cut before you spend another twenty minutes rebuilding.
Where to find Editor.log
| Operating system | Path |
|---|---|
| Windows | %LOCALAPPDATA%\Unity\Editor\Editor.log |
| macOS | ~/Library/Logs/Unity/Editor.log |
| Linux | ~/.config/unity3d/Editor.log |
Unity writes the build report when a player build finishes, so the log contains nothing useful until you have built at least once. The log also accumulates: every build appends another report without removing the last, so a log from a long session can hold several. Unity truncates it when the Editor restarts and renames the old one to Editor-prev.log, so copy the file before you reopen the project.
Two files you can use, and why the build report is better
Every Unity build writes two records of what went into it. Editor.log is the one everybody knows about. The other is Library/LastBuild.buildreport, a binary file in your project that holds the same build described far more precisely. The analyser above reads either, and works out which one you gave it from the file itself rather than from its name.
| Editor.log | LastBuild.buildreport | |
|---|---|---|
| Where it is | Editor.log, in your user profile. Easy to find and easy to send to somebody else. | Library/LastBuild.buildreport, inside the project. Not in version control, and it only ever describes your most recent build. |
| Assets listed | 4,606 entries on the test project. | 9,002 entries on the same build, so the log lists noticeably fewer than the build actually contains. An entry is a packed object rather than a file, so a sprite sheet is listed as both a texture and a sprite; entries sharing a path are combined into one asset before anything is shown. |
| Size accuracy | Rounded to one decimal place, so a 16.2 mb entry could be anywhere in a 50 kB range. | Exact byte counts, for example 17,028,058 bytes. |
| Asset type | Not recorded. Type has to be guessed from the file extension, which is wrong for atlased sprites and .psd sources. | The real Unity class of every asset, so a font is known to be a font rather than assumed from .otf. |
| Platform | Not stated plainly. It has to be inferred from other lines in the log. | Recorded directly in the build summary. |
The figures in that table come from the same build of the same project, read both ways. The log is easier to find and fine for spotting which category is out of control. The build report is worth the extra step whenever you want to act on specific assets, because it names the real Unity type of each one rather than leaving the extension to be guessed at. Note that Library is normally excluded from version control, so the file is on your machine only and follows your most recent build.
What each category means, and which ones you can change
The build report groups everything into eight categories. They are not equally useful: two of them account for most of a typical build, and one of them cannot be reduced at all.
| Category | What it contains | What controls it |
|---|---|---|
| Textures | Every texture in the build after import settings are applied, including sprites, atlases, UI art, normal maps and lightmaps. | The most reducible category by a wide margin. Max Size and compression format are set per platform in the texture importer, and halving a texture's resolution quarters its size. |
| Meshes | Model geometry: vertices, indices, normals, UVs, skin weights and blend shapes. | Mesh Compression in the model importer, and turning off Read/Write Enabled where you do not modify the mesh at runtime, which otherwise keeps a second copy. |
| Animations | Animation clips, including imported clips and Animator state data. | Anim. Compression and the keyframe reduction tolerances in the model importer. Long clips at high sample rates are the usual cause. |
| Sounds | Audio clips as imported into the player build. | Compression Format, Quality and Force To Mono in the audio importer. Reads as zero when audio is delivered by Addressables or by middleware such as Wwise or FMOD. |
| Shaders | Compiled shader variants. One shader with several multi_compile keywords becomes many variants in the build. | Variant stripping, keyword declarations, and the Shader Variant Collection. A single careless multi_compile can multiply the count. |
| Levels | Scene data: the objects, components and serialised values in each scene in the build. | Which scenes are in Build Settings at all, and whether large amounts of data are baked into scenes rather than loaded. |
| Other Assets | Everything without a named category: ScriptableObjects, fonts, TextAssets, serialised data and package content. | Often the second largest category and the log does not break it down further. Use the asset list above to see what is in it. Fonts with large character sets are a common surprise. |
| File headers | Serialisation overhead for the files in the build. | Not meaningfully reducible. Ignore this one unless it is unusually large, which suggests a very high file count. |
In practice Textures is where the wins are. If your report shows textures at more than half the total, start with the texture compression comparison and check the format and Max Size for your target platform before you delete anything. If Sounds is large, the audio import settings reference covers which Compression Format and Load Type to use for music, sound effects and dialogue. A large Shaders figure usually means variant count rather than shader count, which the shader keywords reference explains.
Why the Resources folder is usually the culprit
Unity includes everything in a folder named Resources in the build, whether or not anything references it. This is not a bug and it is not something the build pipeline can improve on. Resources.Load takes a string path resolved at runtime, so there is no reference for Unity to follow at build time and no way for it to know which assets you will ask for. The only safe assumption is that you might ask for any of them, so all of them ship.
The rule applies to every folder called Resources at any depth, not just one at the top of Assets. Packages and asset store imports bring their own, and those ship too. It is common to find several megabytes of demo content, example scenes and unused prefabs in a build purely because they were placed inside a Resources folder by somebody else.
The fix is to stop using Resources for anything large. Reference assets directly from a serialised field where you can, so Unity includes exactly what is used, or move them to Addressables where you genuinely need to load by name. Both give you the same runtime flexibility without shipping the entire folder. The analyser above flags everything it finds in a Resources folder so you can see the size of the problem before deciding.
Uncompressed size versus what players download
Every number in the build report is uncompressed, and the report gives two of them. Total User Assets is the sum of the content you made, and it is what the category percentages are calculated against. Complete build size is the entire uncompressed build output, which also includes the engine, IL2CPP generated code, native plugins and platform libraries. On a real project those two figures were 167 MB and 1.4 GB. The gap is normal.
Neither number is your store download size, and there is no fixed ratio between them. Three separate things shrink the figure between your build folder and a player's device. The store compresses the package. Both Google Play and the App Store then split it, so a device downloads only the CPU architecture and the texture and density variants it can actually use rather than all of them. And anything you deliver through Play Asset Delivery, on-demand resources or Addressables is not in the initial download at all.
So use the build report for what it is good at: telling you what is large relative to everything else in your project, and letting you check whether a change made a difference. Do not use it to predict the number on your store listing, because it cannot. The only reliable way to know your download size is to upload a build and read the figure the store reports back.
Platform size limits worth knowing
| Platform | Limit | What it actually means |
|---|---|---|
| Google Play, app bundle | 150 MB base download | Applies to the compressed download size a device actually receives, not to your uncompressed build. Content beyond it ships through Play Asset Delivery as install-time, fast-follow or on-demand packs. |
| Google Play, legacy APK | 100 MB | Historical, and only relevant if you distribute an APK outside Play. New apps on Google Play have had to use the app bundle format since 2021. |
| iOS App Store | Around 200 MB over cellular | Above the threshold users are prompted to wait for Wi-Fi, which measurably costs installs. App thinning means each device downloads only its own architecture and asset variants, so the delivered size is well below the uncompressed figure. |
| WebGL | No hard limit, but the first load is the whole game | There is no store gate, only patience. Keep the initial download small enough to load in a few seconds on a normal connection and stream the rest, and make sure Brotli or gzip compression is actually enabled on the host. |
These thresholds apply to the compressed, delivered size, so a build whose uncompressed report reads several hundred megabytes may still be comfortably inside them. Check the current figures against the Google Play and App Store documentation before you plan around them, since both have been revised more than once.
Built by David Edgecombe at Ocean View Games, a Unity studio in London.
Related Tools
Texture Compression
Compare ASTC, ETC2, BC7, and more. VRAM costs, platform support, and quality ratings side by side.
Audio Import Settings
Recommended Unity audio clip import settings for music, SFX, UI, dialogue, and more.
Frame Budget Calculator
CPU/GPU budget breakdown by platform and target frame rate.
Shader Keywords
Why setting a texture from code does nothing. Standard and URP shader keywords, and the property each one gates.
Frequently asked questions
Where do I find Editor.log?
Why is Complete build size so much larger than Total User Assets?
Is this the size my players will download?
Why does my audio show as 0 bytes?
What is in Other Assets?
Does my log get uploaded anywhere?
My log has several builds in it. Which one does this show?
Last updated: