How to Use AssetRipper

Before you begin

Use AssetRipper only with files you own, created, are preserving with permission, or are otherwise authorized to inspect. The tool can expose project data, but it does not grant a license to publish or redistribute someone else's models, textures, audio, scenes, or scripts. Keep the original source directory unchanged and work from a copy when possible.

You will also need enough disk space for both the source and the export. A reconstructed Unity project can be much larger than the files you first selected because it may include generated folders, converted textures, serialized data, and a large number of small assets.

The five-step AssetRipper workflow

Choose the right export mode

Do not judge the whole tool by a single empty model or a missing shader. Export support is content-specific. A project can contain readable textures but unsupported materials, or a mesh can appear without the external dependency that gives it the final look.

If the first result is incomplete

Record the input path, Unity version if known, AssetRipper version, export mode, and the exact warning. Then test a smaller input and compare the result. This helps separate a parser limitation from a path-selection mistake, a missing dependency, or a problem in the target viewer.

If AssetRipper reports no files loaded, confirm that the selected directory actually contains Unity serialized files or bundles. If the application crashes during export, reduce the scope, use a writable output path, close other memory-heavy applications, and try again with the stable release before switching to a development build.

How to use AssetRipper for a repeatable test

Once you know how to use AssetRipper, make the workflow repeatable before you attempt a large export. Create a small test folder with a descriptive name, copy only the authorized input you intend to inspect, and note the AssetRipper version beside the test. This gives you a stable baseline when a later build, Unity version, or export mode behaves differently.

Separate three locations whenever possible: the original source, a temporary working copy, and the final export. The source stays untouched, the working copy is where you can test a different folder level or dependency set, and the final export can be opened in Unity or another viewer without mixing it with the next experiment. Clear names such as unity-test-01 or bundle-with-shared-assets are more useful than folders named new or final.

Review the result in the tool that matches your goal. A Unity Project export should be checked in a compatible editor, a GLB should be checked in a viewer that can resolve external textures, and an audio or image export should be opened independently. A successful export means the files were written; it does not automatically mean that every reference, shader, material, rig, or animation survived reconstruction.

The most useful beginner habit is to keep a short run note. Write what you loaded, what AssetRipper recognized, which export mode you selected, and what you expected to see. When you learn how to use AssetRipper through small comparisons, a warning becomes a clue you can act on instead of a reason to restart the entire process.

If you are showing a teammate how to use AssetRipper, demonstrate one small input from start to finish and explain why each folder and export choice was made. A repeatable example is more helpful than a list of buttons because it teaches the boundary between source files, recognized content, generated output, and the separate viewer or Unity editor used for review.

The first successful AssetRipper run should be deliberately small. Use one authorized Unity file, one asset bundle, or one project folder that you can identify, then keep the output in a new writable directory. A small input makes the file list, warnings, and export mode easier to understand. Once that baseline works, add related resources instead of loading an entire build without knowing which dependency caused a change.

A repeatable AssetRipper workflow also depends on careful notes. Write down the release version, Unity version clue, selected folder, output mode, and exact warning text. If the result changes after you add a dependency or move a file, you can compare the two tests. This approach is faster than repeatedly changing versions, deleting output folders, and guessing which step made the project appear incomplete.

• Write down the input path, file type, Unity version clue, export mode, output path, and the warning text before changing a variable.
• Run one small input first, then add dependencies one group at a time so a new warning has a clear cause.
• Keep a screenshot or text note of the recognized asset count when comparing two builds or two export settings.
• Stop and ask for project-owner guidance when the input is protected, encrypted, private, or outside your permission to inspect.