The UE modding tools list is organised around Pak versus IoStore

Every entry names the container format it handles

The first category in the list is packers and unpackers, and reading its entries is the fastest way to understand the problem this repository indexes.

Unreal games ship their cooked assets inside archives. There are two container systems, and which one a game uses decides your entire toolchain.

The list covers tools for Pak and IoStore. IoStore consists of a `.ucas` file for bulk data and a `.utoc` file for the table of contents, sometimes alongside a `.pak`. That distinction appears in almost every entry, usually as a limitation.

`repak` supports reading and writing all Pak versions with compression and encryption, is multithreaded and described as roughly twice as fast as the built-in UnrealPak tool, and does not work for IoStore containers. That last sentence is the pattern.

`retoc` is the IoStore counterpart, a CLI for packing and unpacking `.ucas`/`.utoc` plus `.pak`, and it also converts between Zen assets and legacy `.uasset`/`.uexp` assets. The conversion is what makes the ecosystem usable: you can extract Zen assets, edit them with a legacy tool, and pack them back.

`UnrealReZen` packs IoStore containers but only works with the Zen asset format, which the entry explicitly notes is not the same as legacy cooked assets.

So the shape of the list is a matrix. For each container format, there is a reader, a writer, a converter and a GUI, and the versions each supports are stated. That is a genuine reference, and it is what makes the repository worth more than a search engine query.

The CU and PW tags say how much weight to give an entry

The list uses two tags, and they encode the author's judgement rather than a technical fact.

`[CU]` before a tool means commonly used by multiple UE modding communities. `[PW]` means paywalled. The README does not define any other tags.

The README also says categories are not ordered by any means except that CU tools are at the top. The README says that CU tools are placed at the top of each category.

That matters because the categories also show that several tools in the same category do the same job. In packers and unpackers there are `PakMaster`, which is a GUI wrapper over repak, ZenTools and UnrealPak, and separate repak wrapper scripts for Windows. There is `IOStorePackager`, a simple GUI made with `tuw`. And there is `U4Pak`, a Rust port alongside the original.

So the list is not telling you there is one right answer. It is telling you which ones people converge on and which ones exist for people who cannot use a command line.

The `[CU]` tag on `UE Viewer (AKA UModel)` and on `FModel` in the asset explorer category tells you the same thing in that category: there is a standard tool for looking at assets, and a standard tool for browsing them.

`QuickBMS` is tagged CU with a caveat that it does not work for IoStore, which is a good illustration of why the tags are not endorsements of fitness.

Deprecated entries stay in the list because the format history matters

Three entries in the visible list are marked deprecated, and they are still described in full. That is a deliberate editorial choice and the README explains it.

The warning says some tools may be unmaintained and outdated, but are still useful for people writing their own tools and may want to see how others implemented their tools.

`ZenTools (deprecated)` extracts cooked packages from IoStore containers and the entry notes it only supports UE5.1 to 5.4, with the fixes for 5.3 and 5.4 not uploaded to the original repository, and it directs you to `retoc` to repack. `ZenTools UE4 (deprecated)` is a fork supporting only 4.25 to 4.27, described as all the UE4 IoStore versions, with a link to a gist describing a repack method using UnrealPak and a note that `retoc` can be used with varying results for those versions.

`unpak` is described as a no-nonsense pak parser that does not force files to be extracted and only converts entries to bytes when requested, and it is deprecated in favour of `repak`.

Each of those entries documents not just the tool but the gap it leaves and what to do instead. For someone maintaining an old mod, that is the part that matters: `ZenTools UE4` supports the UE4 versions that `retoc` handles less well, so the deprecated fork is still the practical choice for that range.

The version ranges are the other half of this. `UAssetAPI` is stated as reading and writing UE4 `.uasset` files from 4.0 to 4.27+, and `UnrealPak` is called an UnrealPak version from 2016 that is seemingly compatible with any UE4 game.

A tool list without version ranges would be much shorter and much less useful. These are the numbers that tell you whether a tool can even open your game's files.

Asset editors form a second stack with its own division of labour

The second category covers asset editors, parsers and explorers, and it is described as dealing with `.uasset`, `.uexp`, `.ucas`, `.utoc` and `.umap` files.

The division is between viewing, exploring and editing.

`UE Viewer (AKA UModel)` is the standard tool for viewing and extracting game content, particularly models and textures, and the entry notes it was formerly known as UModel. `FModel` is for exploring a game's files, from seeing an asset's properties to listening to audio files inside them.

`CUE4Parse` is a C# parser and API for UE packages and assets, maintained by the FModel developers and used primarily by FModel. So the browser and the parser behind it are separate projects with a shared team, which is worth knowing if you are following one of them.

Editing is `UAssetGUI`, a GUI for `UAssetAPI`, and `UAssetAPI` itself, a C# API for reading and writing `.uasset` files. A GUI over an API is a common split, and it means a tool you script against is the API rather than the window.

`Kismet Analyzer` is described as a tool for analyzing and manipulating Kismet bytecode in cooked assets, which is the Blueprint bytecode layer.

The categories beyond this one are not visible in what is published here, though the repository topics list animation, automation, mapping, modelling, reversing and sdk generation, and the README links to a developer guide for people who are UE game developers and want to know how these tools are used to mod their games.

The repository itself is almost nothing but the README plus a `Loose Files/` directory, which is where the entries that cannot be linked to a repository live, such as the ZenTools builds and the IOStorePackager archive.

Editorial conclusion

Adopt this list as a starting index if you are modding a game you have the rights to, since the per-tool version ranges and deprecation notes save more time than they cost. Skip it as a dependency, because it is a document rather than a tool and nothing here is guaranteed stable. Verify first which container format your target game ships, whether Pak or IoStore, because the two need different tools end to end and several entries handle only one.

Frequently asked questions

Official sources

1. Buckminsterfullerene02/UE-Modding-Tools on GitHub
2. Issues
3. README