UnityDataTools: a command line view into Unity AssetBundles and Player builds

Reading Unity build output with no Editor in sight

UnityDataTool is a command line tool and a demonstration of the UnityFileSystemApi native dynamic library. Its stated purpose is analysis of the content of Unity data files, AssetBundles and Player content among them, and the point of the design is that it runs directly on those files without requiring the Editor to be running.

That changes who can do the analysis. The Unity tools WebExtract and binary2text cover similar ground, and the README says this tool covers most of their functionality with better performance while adding capability the others do not have, most visibly the ability to create a SQLite database for detailed analysis of build content. The audience is therefore studio engineers doing build size work: people who need to know which bundle grew, what pulled in a dependency, and how much of the shipped output is texture.

The README also notes the tool is designed to scale for large build outputs and has been used to fine-tune large Unity-based games. The repository doubles as a reference for how UnityFileSystemApi could be used inside your own tooling, so a studio that wants these capabilities in its own build pipeline can read the implementation rather than shelling out to an executable.

Three layers: binary formats, features, and the CLI

The solution is organised in layers, and the directory names in the repository make the split easy to follow. At the base are the libraries that read Unity's binary formats, which the tree shows as SerializedFile/, UnityBinaryFormat/, UnityFileSystem/ and Archive/, alongside UnityDataModels/ for the object model those readers expose.

On top sit the feature libraries that turn raw data into something usable: Analyzer/, which produces the SQLite database; TextDumper/, which produces a human-readable dump; and ReferenceFinder/, which produces a reference graph. At the top sits UnityDataTool/, the command line entry point that exposes all of it. There is also a Scripts/ directory, a UnityProjects/ directory, test projects named Analyzer.Tests/, UnityDataTool.Tests/ and UnityFileSystem.Tests/, and a shared TestCommon/ project, plus a global.json that pins the SDK the solution expects.

Two files at the root are worth a look before you plan any automation of your own. AGENTS.md and CLAUDE.md sit next to the code, and the documentation list includes a page on using UnityDataTool with an AI agent that describes the recommended workflow for agents and scripts analyzing a build.

The analyze command and the SQLite database it produces

The feature that distinguishes this tool is analyze, which builds a SQLite database out of a build so the contents can be queried rather than read. The documentation table lists an analyzer page describing the library behind analyze and where each part of the database is documented, a database schema reference covering the tables and views it produces, and a page of worked example queries.

That design matters for large projects. A text dump of a build is something you read once and then scroll through, while a database is something you ask questions of, and the questions are the ones a build engineer actually has: which assets are duplicated across bundles, which dependency pulls in a large library, how the sizes move between two builds. The reference graph produced by ReferenceFinder answers the dependency half of that, and the documentation on comparing builds covers the difference between two builds.

The database is also the point where the tool earns its keep on content directory builds. The documentation covers Content Directory Format, which the README describes as a Unity 6.6 and later feature that produces a build history, and ContentLayout.json, the build layout file that maps content directory build output back to source assets. That mapping is the difference between seeing that a file exists and understanding which asset produced it.

Addressables build reports, build reports and the AI agent guide

Beyond the binary formats, the tool parses reports. The README describes comprehensive analysis of Unity Addressables build reports, with automatic detection and parsing of Addressables JSON build outputs to extract information about bundles, assets, dependencies, file sizes and build performance metrics, and the documentation has a dedicated page for it.

There is a second report path. The build reports documentation covers importing a Unity BuildReport so build output can be mapped back to source assets, which is the same question answered from a different input file. One path reads the artefacts themselves, the other reads what the Editor wrote about them.

The documentation list is broad enough to be worth skimming before you write any scripts: overview of Unity content covering SerializedFiles, Unity Archives and TypeTrees, AssetBundle format with its object, preload tables and scene storage, Player build format including compression, built-in resource files and tips for inspecting Android and Web content, and the command line tool page listing all commands and their options. Start with the command line page and the analyzer schema, then move outward.

Install: self-contained zips and no .NET runtime

Builds for Windows, macOS on Apple Silicon and Linux are attached to every release, and they are self-contained. A zip holds the UnityDataTool executable, the native UnityFileSystemApi library it uses, and an offline copy of the README and the Documentation folder. Nothing else has to be installed, not even a .NET runtime, which is what makes the tool usable on a build agent without installing an SDK.

On Linux and macOS the install is a download, an unzip and a version check:

dest=~/.local/share/UnityDataTool
curl -fsSL -o /tmp/UnityDataTool.zip https://github.com/Unity-Technologies/UnityDataTools/releases/latest/download/UnityDataTool-linux-x64.zip
unzip -oq /tmp/UnityDataTool.zip -d "$dest" && "$dest/UnityDataTool" --version

The macOS variant uses the same three lines with the Apple Silicon archive name. On Windows the README gives a PowerShell version that installs into %LOCALAPPDATA%\Programs\UnityDataTool. Add the install directory to your PATH to run the tool as UnityDataTool from anywhere.

Two details protect the integrity of the download. The releases/latest/download/ links always resolve to the newest release, and checksums.txt on the release page holds the SHA-256 of each zip, so a build server can verify what it fetched without pinning a version number by hand.

Upgrade traps, the macOS quarantine flag and missing Intel builds

Three rough edges are documented, and each one will bite a script if you do not know about it.

Upgrading means running the same commands again. They overwrite everything the new release ships, but they do not remove a file the new release dropped, so a renamed documentation page can survive as a stale copy. Deleting the install directory first gives an install that matches the release exactly, and that is the behaviour a reproducible build agent should implement.

On macOS, downloading with curl avoids the quarantine flag a browser download sets. After a browser download the system may refuse to load UnityFileSystemApi.dylib until it is allowed under System Settings, Privacy & Security, which is a manual step that a fresh CI machine does not have. Intel Macs have no published build at all, so those machines need the build from source route instead.

That leaves a platform boundary worth stating plainly. Published binaries cover Windows, Apple Silicon macOS and Linux, and the Intel Mac gap is the one place where the self-contained install story breaks.

A custom licence, a recent release line and what to check first

The licence is the first thing to resolve. The repository listing classifies it as Other because GitHub cannot categorise the custom LICENSE file, and LICENSE.md in the tree is the text that governs. That is unusual for a Unity-Technologies repository and it is not something the README explains, so read it before you build a process on top of the tool.

The release history, by contrast, is reassuringly ordinary. v2.2.1 on 2026-09-15 added Linux releases and usability fixes, v2.3.0 on 2026-09-23 added Unity 6.7 support, and v2.4.0 on 2026-10-02 brought usability improvements and Unity 6.7 support. The last push was on 2026-10-16, so the project is moving quickly enough that the version support matrix is worth rechecking before each Unity upgrade.

One structural note for anyone automating this. The command line tool is a demonstration of a native library, and the documentation explicitly frames the repository as a reference for how that library could be used in your own tools. That means the CLI surface is the supported contract, while the library layer is more likely to change under you. Drive the executable from a script, and treat the C# API as something to read rather than to bind against.

Editorial conclusion

Adopt UnityDataTools if you ship Unity games and need to inspect AssetBundles, Player content or Addressables build output on a build machine where the Editor is unavailable or too slow, and if you are prepared to read the LICENSE.md file first. Do not adopt it expecting a supported library with a stable public API, since the project describes itself as a demonstration and reference for the native UnityFileSystemApi library and carries a custom licence that GitHub cannot classify. Verify three things first: that the licence permits your intended use, whether commercial distribution of a game built with these tools is affected, and which Unity version your build output targets, since content directory builds are documented for Unity 6.6 and later while release v2.4.0 added Unity 6.7 support. The last push was on 2026-10-16 and the newest release is v2.4.0 dated 2026-10-02.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Unity-Technologies/UnityDataTools on GitHub