Toggle menu
Toggle preferences menu
Toggle personal menu
Not logged in
Your IP address will be publicly visible if you make any edits.

Minecraft:Bedrock Edition level format

From SAS Gaming Wiki
Revision as of 11:04, 16 October 2026 by SyncBot (talk | contribs) (Sync: updated from Minecraft)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Template:Exclusive Template:Update

Bedrock Edition stores world data in a modified version of Google's LevelDB with zlib compression support. World settings are stored separately in Template:Cd. Each world has its own directory containing these files.<ref name="mojang-leveldb">Mojang: LevelDB implementation</ref>

World files and locations

  • Template:Cd - the database containing terrain, entities, and other world data.
  • Template:Cd - world settings in little-endian NBT, preceded by an eight-byte header.
  • Template:Cd - a previous copy of the world settings, when present.
  • level.dat_new - a temporary copy of the world settings used while saving the level.dat file, will only be present while saving or if the game crashed while saving the level.dat. The game writes the data to level.dat_new, deletes level.dat_old. renames level.dat to level.dat_old, and renames level.dat_new to level.dat.
  • Template:Cd - the world name.
  • Template:Cd - the world thumbnail, when present.

World locations depend on the platform and installation. On Windows, 1.21.120 migrated the game from UWP to GDK and moved its content under Template:Cd. Earlier Windows installations used Template:Cd.<ref>Microsoft Learn: GDK migration on Windows</ref><ref>Mojang: Bedrock Edition 1.21.120 changelog</ref> See Minecraft:com.mojang for platform-specific locations.

26.40 added Windows world cloud backup and synchronization.<ref name="release-2640">Mojang: Bedrock Edition 26.40 changelog</ref>

LevelDB format

Mojang variant

Mojang's LevelDB implementation extends Google's LevelDB with zlib compression support. Database readers must support the compression types used by the world.<ref name="mojang-leveldb" /> A Java implementation is available as leveldb-mcpe-java.

The database is stored in the world's Template:Cd directory. Pass this directory to the LevelDB API rather than an individual database file. LevelDB manages its table files, journals, and manifests together.<ref name="leveldb-files">Google: LevelDB implementation</ref>

Chunk key format

A database key for data regarding a chunk is the concatenation of:

  • Two signed 32-bit little-endian integers (x and z in chunk coordinates, respectively),
  • An optional third 32-bit little-endian integer (1 for the Minecraft:Nether, 2 for the Minecraft:End, omitted for the Minecraft:Overworld, except for "JigsawStructureBlueprint" records, where this third integer is always present),
  • A one-byte tag specifying the type of record represented by the key (see table),
  • (for a "SubChunkPrefix" record) a signed one-byte subchunk Y index, and
  • (for a "JigsawStructureBlueprint" record) an eight-byte structure ID.

Accordingly, such a key may be 9, 10, 13, 14, or 21 bytes long. Not all subchunks necessarily exist for a given chunk. The Y index is the block Y coordinate divided by 16, rounded down. Negative indices represent terrain below Y=0; readers must not assume every dimension has only 16 subchunks.<ref name="subchunk-code">arnis: Bedrock world reader and writer</ref>

The "BlockEntity" and legacy "Entity" records are represented by a sequence of concatenated root tags in a variant of Minecraft:NBT which stores the lengths and the multi-byte integer types in little-endian format, as opposed to the big-endian format used by Template:El or the original NBT specification.

The Template:Cd record identifies the chunk storage version. It is separate from the subchunk version, the Template:Cd header version, and the network protocol version.

Key type tags
Tag byte Name Structure Description
Dec Hex ASCII
43 2B Template:Cd Data3D Heightmap (256×2 bytes)

Biome data (varying lengths)

Biomes are stored as palettes similar to blocks. The layout depends on the storage version and dimension. Template:Info needed
44 2C Template:Cd Version 1 byte A byte
45 2D Template:Cd Data2D Heightmap (256×2 bytes)

2D biomes (256×1 bytes or 256×2 bytes)

Biome IDs are written as 8-bit integers (or 16-bit little-endian integers in v1.21.40.23+). No longer written since v1.18.0, except for worlds using the Minecraft:Old world type or an older base game version (the Template:Cd level.dat property).
46 2E Template:Cd Data2DLegacy Heightmap (256×2 bytes)

2D biomes (256×4 bytes)

Each entry of the biome array contains a biome ID in the first byte, and the final 3 bytes are red/green/blue respectively. No longer written since v1.0.0.
47 2F Template:Cd SubChunkPrefix Subchunk version (1 byte) Version-dependent data Terrain for a 16×16×16 subchunk
48 30 Template:Cd LegacyTerrain Block IDs (32768 bytes)

Block meta (32768 nibbles)

Block sky light (32768 nibbles)

Block light (32768 nibbles)

Heightmap (256×1 bytes)

2D biomes (256×4 bytes)

Data ordered in XZY order, unlike Java.

No longer written since v1.0.0.

Biomes are IDs plus RGB colours similar to Data2DLegacy.

49 31 Template:Cd BlockEntity List of NBT compound roots Minecraft:Block entity data (little-endian NBT)
50 32 Template:Cd Entity List of NBT compound roots Legacy Minecraft:entity data (little-endian NBT). See Entity storage for modern records.
51 33 Template:Cd PendingTicks NBT compound root Pending tick data (little-endian NBT)
52 34 Template:Cd LegacyBlockExtraData Entry count (4 bytes)

Entries: Key (4 bytes), Value (2 bytes).

Array of blocks that appear in the same place as other blocks. Used for grass appearing inside snow layers prior to v1.2.13. No longer written as of v1.2.13.
53 35 Template:Cd BiomeState
54 36 Template:Cd FinalizedState 4 bytes A 32-bit little endian integer
55 37 Template:Cd ConversionData No longer used
56 38 Template:Cd BorderBlocks Education Edition Feature
57 39 Template:Cd HardcodedSpawners Bounding boxes for structure spawns stored in binary format
58 3A Template:Cd RandomTicks NBT compound root Random tick data (little-endian NBT)
59 3B Template:Cd Checksums xxHash checksums of other chunk records. No longer written as of v1.18.0.
61 3D Template:Cd MetaDataHash
62 3E Template:Cd GeneratedPreCavesAndCliffsBlending Not used
63 3F Template:Cd BlendingBiomeHeight Not used
64 40 Template:Cd BlendingData
65 41 Template:Cd ActorDigestVersion
118 76 Template:Cd LegacyVersion 1 byte Moved to 44 in v1.16.100
119 77 Template:Cd AABBVolumes
120 78 Template:Cd JigsawStructureBlueprint

The tag assignments are version-dependent. Microsoft's published actor-storage documentation gives different assignments for tags Template:Cd-Template:Cd from the table above. These entries require verification against the world version being read.<ref name="actor-storage">Microsoft Learn: Actor storage in Minecraft</ref>

Subchunk storage

A subchunk contains a 16×16×16 block volume. Paletted subchunks store block indices and a palette of block states.

Version Header
8 Version byte and one-byte storage-layer count.
9 Version byte, storage-layer count, and signed one-byte subchunk Y index.

Each layer starts with a byte whose upper seven bits specify the bits per palette index. Bit 0 distinguishes persistent palettes from runtime palettes. Disk block palettes use little-endian NBT rather than network runtime IDs.

For nonzero bit widths, indices occupy little-endian 32-bit words. Each word holds Template:Cd indices; remaining bits are padding. The 4096 indices use XZY order, with Y changing fastest. The index words are followed by a four-byte little-endian palette count and the palette's NBT compounds.<ref name="subchunk-code" /> Multiple layers allow blocks and fluids to occupy the same position.<ref>Tommaso Checchi: Block changes in Beta 1.2.13</ref>

Entity storage

Modern worlds store entities individually under Template:Cd keys. An entity's ID remains stable between play sessions and is unique within its world. Separate Template:Cd records hold the chunk's entity-key digest. Readers must handle these records rather than relying only on the legacy Template:Cd chunk record.<ref name="actor-storage" /> Block entities use their separate chunk record.

Other keys

There's also the special key ~local_player for an entity data entry that holds the local player entity. The value associated with the ~local_player key is NBT encoded and has only a single compound tag at the root level.

Remote-player records use keys beginning with Template:Cd. The suffix depends on the identity system and world version; the historical Template:Cd convention does not describe every current world. Values contain a little-endian NBT root compound.

There's also a special "game_flatworldlayers" key of length 20 for flat worlds. The value associated with this key is a set of numbers in ASCII text format. An example of a value associated with the "game_flatworldlayers" key is "[7,3,3,2]" where the value length for this example is 9.

There are several keys related to villages. Depending on the dimension, the village key is prefixed with VILLAGE_DIMENSION_[0-9a-f\\-]+_, with DIMENSION being replaced with the dimension's name.

  • DWELLERS
    • Consists mainly of an entity/mob ID's. Dwellers include villagers, iron golems, and cats.
  • INFO
    • Includes the village bounding box.
  • POI
    • Provides a mapping between villagers and their beds, village center (bell) and work station.
  • PLAYERS

Other keys start with the following strings

  • actorprefix
  • digp
  • legacy_console_player_
  • map_
  • portals
  • schedulerWT
  • structuretemplate
  • tickingarea
  • DynamicProperties
  • scoreboard
  • Overworld
  • Nether
  • TheEnd
  • AutonomousEntities
  • BiomeData
  • mobevents
  • LevelChunkMetaDataDictionary
  • RealmsStoriesData_
  • DedicatedServerForcedCorruption
  • SST_SALOG
  • SST_WORD
  • SST_WORD_

An official explanation from Microsoft about how entities (actors) are stored in LevelDB can be found on Microsoft Learn / Minecraft Bedrock Edition.

Implementations

  • An example implementation of a Bedrock level-db parser can be found in minecraft_mmccoo. This implementation walks the NBTs of all block, entities/mobs, elevations, and village related items.
  • A more up-to-date TypeScript implementation can be found on the mcbe-leveldb NPM package.

NBT structures

The following articles document NBT structures used by world data.

level.dat

The Template:Cd file contains uncompressed little-endian NBT with an eight-byte header. The first four bytes hold the file-format version as a little-endian integer; the next four hold the NBT payload length, excluding the header. Version 10 is used by modern saves. Readers should check the stored version rather than assuming it matches the game release. Template:Info needed

NBT structure

Tags depend on the game version, platform, and world settings. This list includes legacy and optional fields and is not a complete schema for every release. Preserve unrecognized fields when editing a world.

In 26.30, Template:Cd was replaced by Template:Cd. Existing true and false settings migrate to Template:Cd and Template:Cd, respectively. The exact NBT name, type, and stored enum values for the replacement still need documentation.<ref name="release-2630">Mojang: Bedrock Edition 26.30 changelog</ref>

Since 26.40, NBT lists and compounds have a nesting limit of 512.<ref name="release-2640" />

Database files and logs

LevelDB uses several files in Template:Cd:<ref name="leveldb-files" />

The diagnostic Template:Cd is separate from the binary journal format. A diagnostic entry can look like this:

2014/07/24-22:20:08.400488 4a3638 Recovering log #3

History

Template:HistoryTable

See also

References

Template:Reflist

Navigation

Template:Navbox Bedrock Edition

Minecraft:de:Weltdaten (Bedrock) Minecraft:es:Formato de nivel de Bedrock Edition Minecraft:ja:ワールドフォーマット/Bedrock Edition Minecraft:nl:Bedrockeditie level format Minecraft:pt:Formato de nível da Edição Bedrock Minecraft:zh:基岩版存档格式