Java Edition only
The Named Binary Tag format is used by Minecraft for the various files in which it saves data. The format is described by Notch in a very brief specification. The format is designed to store data in a tree structure made up of various tags. All tags have an ID and a name. The original known version was 19132 as introduced in Minecraft Beta 1.3, and since then has been updated to 19133 with Anvil, with the addition of the Int Array tag. The NBT format dates all the way back to Minecraft Indev with tags 0 to 10 in use.
TAG definition[edit | edit source]
A tag is an individual part of the data tree. The first byte in a tag is the tag type (ID), followed by two bytes for the length of the name, then the name as a string in UTF-8 format (Note TAG_End is not named and does not contain the extra 2 bytes; the name is assumed to be empty). The name of tags may contain spaces, although Minecraft itself never saves tags with spaces in the names. Finally, depending on the type of the tag, the bytes that follow are part of that tag's payload. This table describes each of the 12 known tags in version 19133 of the Named Binary Tag format:
|ID||Icon||Tag Type||Payload||Description||Storage Capacity|
|0||TAG_End||None.||Used to mark the end of compound tags. This tag does not have a name, so it is only ever a single byte 0. It may also be the type of empty List tags.||N/A|
||TAG_Byte||1 byte / 8 bits, signed||A signed integral type. Sometimes used for booleans.|| Full range of -(27) to (27 - 1)|
(-128 to 127)
||TAG_Short||2 bytes / 16 bits, signed, big endian||A signed integral type.|| Full range of -(215) to (215 - 1)|
(-32,768 to 32,767)
||TAG_Int||4 bytes / 32 bits, signed, big endian||A signed integral type.|| Full range of -(231) to (231 - 1)|
(-2,147,483,648 to 2,147,483,647)
||TAG_Long||8 bytes / 64 bits, signed, big endian||A signed integral type.|| Full range of -(263) to (263 - 1)|
(-9,223,372,036,854,775,808 to 9,223,372,036,854,775,807)
||TAG_Float||4 bytes / 32 bits, signed, big endian, IEEE 754-2008, binary32||A signed floating point type.|| Precision varies throughout number line;|
See Single-precision floating-point format. Maximum value about 3.4*1038
||TAG_Double||8 bytes / 64 bits, signed, big endian, IEEE 754-2008, binary64||A signed floating point type.|| Precision varies throughout number line;|
See Double-precision floating-point format. Maximum value about 1.8*10308
||TAG_Byte_Array||TAG_Int's payload size, then size TAG_Byte's payloads.||An array of bytes.||Maximum number of elements ranges between (231 - 9) and (231 - 1) (2,147,483,639 and 2,147,483,647), depending on the specific JVM.|
||TAG_String||TAG_Short's payload length, then a UTF-8 string with size length.||A UTF-8 string. It has a size, rather than being null terminated.||32,767 bytes interpretable as UTF-8 (see UTF-8 format; most commonly-used characters are a single byte).|
||TAG_List||TAG_Byte's payload tagId, then TAG_Int's payload size, then size tags' payloads, all of type tagId.||A list of tag payloads, without repeated tag IDs or any tag names.||Due to JVM limitations and the implementation of ArrayList, the maximum number of list elements is (231 - 9), or 2,147,483,639. Also note that List and Compound tags may not be nested beyond a depth of 512.|
||TAG_Compound||Fully formed tags, followed by a TAG_End.||A list of fully formed tags, including their IDs, names, and payloads. No two tags may have the same name.||Unlike lists, there is no hard limit to the amount of tags within a Compound (of course, there is always the implicit limit of virtual memory). Note, however, that Compound and List tags may not be nested beyond a depth of 512.|
||TAG_Int_Array||TAG_Int's payload size, then size TAG_Int's payloads.||An array of TAG_Int's payloads.||Maximum number of elements ranges between (231 - 9) and (231 - 1) (2,147,483,639 and 2,147,483,647), depending on the specific JVM.|
||TAG_Long_Array||TAG_Int's payload size, then size TAG_Long's payloads.||An array of TAG_Long's payloads.||Maximum number of elements ranges between (231 - 9) and (231 - 1) (2,147,483,639 and 2,147,483,647), depending on the specific JVM.|
The List and Compound tags can be and often are recursively nested. It should also be noted that, in a list of lists, each of the sub-lists can list a different kind of tag.
File Format[edit | edit source]
An NBT file is a GZip'd Compound tag, name and tag ID included. Some of the files utilized by Minecraft may be uncompressed, but in most cases the files follow Notch's original specification and are compressed with GZip. In the Xbox 360 Edition, chunks are compressed with XMemCompress, a variation of an LZX compression algorithm. There is no header to specify the version or any other information - only the level.dat file specifies the version.
As used in Minecraft[edit | edit source]
Minecraft's use of the NBT format is odd at times. In some instances, empty lists may be represented as a list of Byte tags rather than a list of the correct type, or as a list of End tags in newer versions of Minecraft, which can break some older NBT tools. Additionally, almost every root tag has an empty name string and encapsulates only one Compound tag with the actual data and a name. For instance:
The root tag for most Minecraft NBT structures.
SomeName: The only tag contained within the root tag - it has a name and contains all the actual data.
Another noticeable oddity is that, although the original specification by Notch allows for spaces in tag names, and even the example uses spaces in the tag names, Minecraft has no known files where any tags have spaces in their names. There is also inconsistent use of letter case, mostly either lowerCamelCase or UpperCamelCase, but sometimes even in all lowercase.
Uses[edit | edit source]
- level.dat is stored in compressed NBT format.
- <player>.dat files are stored in compressed NBT format.
- idcounts.dat is stored in uncompressed NBT format.
- villages.dat is stored in compressed NBT format.
- map_<#>.dat files are stored in compressed NBT format.
- servers.dat, which is used to store the list of saved multiplayer servers as uncompressed NBT.
- Chunks are stored in compressed NBT format within Region files.
- scoreboard.dat is stored in compressed NBT format.
- Generated structures are stored in compressed NBT format.
- Saved Structures are stored in compressed NBT format.
Software[edit | edit source]
Mojang has provided sample Java NBT classes for developers to use and reference as part of the source code for the McRegion -> Anvil converter. Other than this, the community has developed programs to view and modify compressed and uncompressed NBT files:
|MineBack Ultimate||19133||MineBack Ultimate provides a full NBT editor supporting all available types of NBT format file (Map, Level, World etc.). It comes with a modern GUI and many helper functions.|
|NBTEdit||19132||Allows for viewing and modifying NBT files via a Windows tree control. It is outdated not only from being an NBT version behind, but because it does not support multiple tags with the same name and it forces incorrect ranges on some types, and it lacks support for uncompressed NBT files.|
|NBTExplorer - Forum Post||19133||Inspired by and based on NBTEdit, this program allows viewing and editing of NBT files via a Windows tree control. It supports compressed and uncompressed NBT files, and allows for direct editing of the NBT structures in MCRegion and Anvil files, level.dat, etc.|
|NBT grammar for Synalyze It!||19132||Using this grammar Synalyze It! displays a color-coded hex dump along with the parsed tag tree. Currently only uncompressed files are supported.|
|NEINedit||19132||NBT editor for mac with a text-based tree structure.|
|NBT2YAML||19133||nbt2yaml presents a command line interface for reading and editing Minecraft NBT files using a custom YAML format. It also includes a Python API for parsing and writing NBT files to/from a simple Python data structure.|
|webNBT||19133||webNBT is an NBT-editor that runs in modern browsers without requiring the user to download an application or use third-party browser plugins (like Flash or Java).|