brpak format

brpack.md

The .brpak format: Minecraft Bedrock's unshipped "baked pack" container

Status: latent / unshipped. As of Minecraft Bedrock Preview 1.26.50.26 (August 2026), no .brpak file has ever been observed on disk — not in the game payload, not in BDS, not in any local cache. Everything below is datamined from reader/writer code that already exists inside bedrock_server.exe. Treat the "format" section as verified-by-error-strings and the "purpose" section as informed inference.

TL;DR

.brpak is a pack-level container format that Mojang has built but not yet turned on. It is a plain ZIP file whose archive comment must begin with BRPAK/, whose entries must all be STORE (uncompressed), and which is validated strictly enough to safely load untrusted third-party packs. It is produced by an internal BakeTool that "bakes" a pack folder: upgrading its documents to the current format version, compiling them (Cereal/MCB), bundling them into a .brarchive, and wrapping the whole pack into one .brpak. It is consumed through a PreloadCache built for single-file-handle, index-based (likely memory-mapped) reads.

It completes a layering Mojang has been rolling out through 2026:

Layer	Scope	Format
MCB	one compiled document	binary, magic 7F 4D 43 42
.brarchive	a bundle of documents	custom binary, magic 0x7D2725B1
.brpak	an entire pack	ZIP (STORE-only) with BRPAK/ comment

Background

Since ~July 2026, Bedrock Preview ships vanilla pack content as .brarchive bundles under per-pack __brarchive/ directories, with many of the contained *.json files actually being compiled MCB binaries rather than text JSON. That transitional layout still leaves each pack as a directory tree with loose stub files alongside the archives. .brpak looks like the intended endpoint: one sealed file per pack.

Discovery

The Windows client executable (Minecraft.Windows.exe under C:\XboxGames\) is ACL-protected and unreadable, but Bedrock Dedicated Server builds are plain downloads. String-mining bedrock_server.exe from Preview BDS builds surfaces a complete, self-consistent set of .brpak reader/writer diagnostics.

The string set is byte-identical across BDS 1.26.50.22, 1.26.50.25, and 1.26.50.26, so the implementation predates the earliest of those builds (early August 2026) and has not changed since.

Reproduce with ripgrep against any of those builds:

rg -a -o -i '[ -~]{0,60}brpak[ -~]{0,60}' bedrock_server.exe | sort -u

The container format (verified by strings)

Every claim in this section is backed by a validation-error string in the binary (full dump below).

• The file extension is .brpak.
• The container is opened as a ZIP ("Failed to open brpak file as ZIP").
• The ZIP archive comment must begin with BRPAK/ ("Not a valid brpak archive (missing BRPAK/ comment)"). Only the prefix appears as a string constant; whatever follows the slash (a version number? an entry count — see below) is not visible as a static string, so it is presumably written dynamically.
• Every entry must be stored with the ZIP STORE method — no compression ("brpak entry is not STORE compressed").
• Entries must carry CRC and size metadata ("brpak entry is missing CRC metadata" / "missing size metadata").
• An entry count is read and checked ("Failed to read brpak entry count", "brpak has too many entries", "brpak archive is empty"). Where the count comes from (the ZIP end-of-central-directory record, or encoded after BRPAK/ in the comment) cannot be determined from strings alone.
• Entry data offsets are validated ("brpak entry has invalid data offset") and there is a maximum entry size ("brpak entry exceeds maximum allowed size").
• Path hygiene is enforced per entry: no absolute paths, no backslashes, no .. traversal, no duplicate names.
• Lookup goes through a built name index ("Entry not found in brpak index", "failed to build index from: {}").

The combination — STORE-only, offsets validated up front, TOC-indexed — is the classic recipe for reading entries directly off disk or memory-mapping them, with the ZIP framing kept only for tooling compatibility. A consequence worth stating explicitly: any standard zip tool will be able to list and extract a .brpak once files exist; only the comment check and validation rules are bespoke.

Complete .brpak string dump (BDS 1.26.50.22–.26)

.brpak
Entry not found in brpak index
Failed to get brpak entry name
Failed to open brpak file as ZIP
Failed to read brpak entry count
Failed to read brpak entry data
Failed to stat brpak entry
Not a valid brpak archive (missing BRPAK/ comment)
Short read on brpak entry data
brpak archive is empty
brpak contains duplicate entry name
brpak entry contains backslash
brpak entry contains path traversal
brpak entry exceeds maximum allowed size
brpak entry has absolute path
brpak entry has invalid data offset
brpak entry is missing CRC metadata
brpak entry is missing size metadata
brpak entry is not STORE compressed
brpak has too many entries
failed to open brpak for reading: {}
no .brpak file found, nothing to unpack

The producer: BakeTool

The writer side lives in Bedrock::Resources::BakeTool, part of an internal ResourceProcessing module. Source paths embedded in the binary:

handheld/src-deps/ResourceProcessing/src/Archive.cpp
handheld/src-deps/ResourceProcessing/src/Bake.cpp
handheld/src-deps/ResourceProcessing/src/BinaryHeader.cpp
handheld/src-deps/ResourceProcessing/src/PreloadCache.cpp
handheld/src-deps/ResourceProcessing/src/util/MinecraftDocumentUtils.cpp

(Note: handheld/ is Mojang's long-standing internal name for the Bedrock monorepo root — it appears in the PDB path of every BDS build — not a reference to any device.)

This is the same module that owns the Cereal/MCB machinery, which places .brpak firmly in the brarchive/MCB pipeline rather than beside it. Visible BakeTool methods:

bakeSinglePack(Core::PathView, Core::PathView)
bakeFilesInFolder(Core::PathView, Core::PathView, Core::PathView)
optimizeFilesWithArchive(Archive::Builder*, Core::PathView, const std::vector<...>)
writeArchive(Archive::Builder&, Core::PathView)
copyManifestWithVersionStamp(Core::PathView, Core::PathView, SemVersionConstant)
copyRegularFile(Core::PathView, Core::PathView)
outputLog() const

And its log format strings:

bake pack {} to {}, archive root {}
bake folder {} to {}, archive path {}
skip already optimized pack {}
wrote optimized/upgraded file {} to {}
wrote bake stats to {}
write archive {}

Adjacent to this, the binary contains ResourceProcessing::CerealUpgrader template instantiations that migrate documents version-by-version (ActorDocument v1_21_130 → v1_26_20 → v1_26_30 → v1_26_40 → v1_26_50).

Put together, a "bake" of a pack does approximately:

1. Walk the pack folder ("bake pack {} to {}").
2. Upgrade each document to the current format version (CerealUpgrader chain) and compile it ("wrote optimized/upgraded file {} to {}").
3. Feed optimized files into an Archive::Builder and emit a .brarchive ("write archive {}").
4. Re-stamp the manifest with a version (copyManifestWithVersionStamp), copy non-compilable files as-is (copyRegularFile).
5. Package the result as a .brpak and write bake statistics.

"skip already optimized pack {}" implies bakes are idempotent and cached — consistent with an on-device optimize-once step (think shader cache, but for packs), not only an offline build step.

The consumer: PreloadCache

The read side is Bedrock::Resources::PreloadCache:

Bedrock::Resources::PreloadCache::PreloadCache(SharedOnlyConstructionTag, std::weak_ptr<Core::FileHandlePool>...)
PreloadCache::addPreloadedPath(...) -> PreloadedPathHandle
PreloadCache::_cacheTOCReaderSingleFlight(...) -> std::shared_ptr<Archive::TOCReader>
PreloadCache::_findPreloadedPath(const PreloadedContentMaps&, const Core::Path...)
PreloadCache requires a live FileHandlePool

A table-of-contents reader cached per archive, path lookups resolved against preloaded content maps, all funneled through a pooled file handle — i.e., virtual-filesystem-style access into the container without extracting it.

There is also a separate one-shot unpack path ("no .brpak file found, nothing to unpack" / "no {} directory found, nothing to unpack"), suggesting some flow extracts a .brpak to a directory rather than reading it in place.

What it's for (inference)

• Load-time performance. Opening thousands of small files is the expensive part of pack loading, especially on consoles and mobile. One STORE-only, TOC-indexed file per pack collapses that to a single open + index lookups, with zero decompression cost and mmap-friendly layout.
• Moving work from runtime to bake time. Baked packs are pre-upgraded to the current format version and pre-compiled to MCB, so the engine can skip JSON parsing and format-version migration at load.
• Distribution. One file per pack means faster installs, cheaper patching, and built-in integrity (mandatory CRCs). Choosing ZIP as the outer framing — when Mojang already has the custom .brarchive format in the same module — reads as a deliberate interop decision: Bedrock packs already travel as ZIPs (.mcpack), and every platform can produce/inspect one.
• Third-party content. The strict per-entry path validation (traversal, absolute paths, backslashes, duplicates) is what you write when untrusted packs will flow through the format — so this does not look vanilla-only.

Open questions

• What follows BRPAK/ in the archive comment (version? entry count?).
• Where the "entry count" is read from, and the actual limits behind "too many entries" / "maximum allowed size".
• When Mojang flips it on, and for which tier first (vanilla payload, marketplace, dev tooling).
• Whether the client gets a user-facing bake step for downloaded/imported packs, as "skip already optimized pack" hints.
• Whether .brpak replaces the current __brarchive/ directory layout or wraps it.

Reproducing this research

1. Download a Preview BDS build ≥ 1.26.50.22 (bedrock-server-<ver>.zip from minecraft.net — note BDS often publishes a version before it reaches Preview players).
2. Run the string extraction above against bedrock_server.exe; widen the window and pivot on BakeTool, ResourceProcessing, and PreloadCache for the pipeline context.
3. The Windows client exe cannot be read directly (XboxGames ACLs), so BDS is the practical mining target; client and server share the engine.

---

Researched August 2026 against Bedrock Preview / BDS 1.26.50.22–1.26.50.26. Nothing here comes from leaked source or private builds — only strings shipped inside public BDS binaries. Related reading: the .brarchive format, the MCB binary format, bedrock-crustaceans/brarchive.