Compatible con Minecraft Bedrock Edition y Java Edition, y con todos sus núcleos de servidor, conocidos o no: Vanilla, Paper, Spigot, Purpur, Folia, Fabric, Forge, NeoForge, Mohist, Sponge, Bedrock Dedicated Server, PocketMine-MP, Nukkit, PowerNukkitX, Cloudburst, Dragonfly, Endstone, LeviLamina y el resto. Lista completa.
NBT (Named Binary Tag) es el formato de árbol binario de Minecraft: una etiqueta contiene un tipo de un byte, un nombre precedido por su longitud y una carga útil; los compuestos se anidan hasta que un byte TAG_End los cierra. Existen 13 tipos de etiquetas y cinco codificaciones usadas por Java y Bedrock. Esta página las documenta y el editor permite comprobarlas con archivos reales.
13 tipos de etiquetasBig-endianLittle-endianVarintgzipzlibSNBT
Arrastra cualquier archivo NBT para inspeccionar aquí
Un archivo contiene un solo TAG_Compound raíz: un byte de tipo 0x0A, un nombre y el contenido del compuesto. Las etiquetas con nombre solo aparecen dentro de compuestos; los elementos de listas llevan únicamente la carga, por eso una lista es homogénea.
Cinco codificaciones en uso
Codificación
Enteros
Longitud de cadena
Raíz
Uso
Java (clásica)
Big-endian de ancho fijo
2 bytes big-endian
Con nombre
Mundos, estructuras y esquemas de Java
Red Java (1.20.2+)
Big-endian de ancho fijo
2 bytes big-endian
Sin nombre
Protocolo de Java
Bedrock
Little-endian de ancho fijo
2 bytes little-endian
Con nombre
Mundos Bedrock, .mcstructure y valores LevelDB
level.dat de Bedrock
Little-endian de ancho fijo
2 bytes little-endian
Con nombre, tras un encabezado de 8 bytes
Metadatos de mundos Bedrock
Red Bedrock
Varint zigzag para int y long
Varint sin signo
Con nombre
Protocolo de Bedrock
En la codificación varint, TAG_Short, TAG_Float y TAG_Double siguen siendo little-endian de ancho fijo. Solo TAG_Int y TAG_Long pasan a varints zigzag, y las longitudes de arreglos y listas siguen a TAG_Int. Las longitudes de cadenas son varints sin signo y no tienen el límite de 65535 bytes de las codificaciones fijas.
Cadenas: UTF-8 modificado frente a UTF-8
Java serializa cadenas con DataOutputStream.writeUTF, un UTF-8 modificado: NUL se escribe como C0 80 y no como 00, mientras que los caracteres fuera del plano multilingüe básico se dividen en dos mitades sustitutas de tres bytes (CESU-8), no en una secuencia de cuatro. Bedrock usa UTF-8 estándar. Usar una sola codificación para ambos daña emojis y parte del texto CJK; este editor codifica según el formato.
Compresión
NBT no incluye compresión; la decide el contenedor. Los archivos Java suelen usar gzip (firma 1F 8B), las cargas de chunks dentro de regiones usan zlib (firma 78 01, 78 9C o 78 DA) y Bedrock guarda level.dat y las estructuras sin comprimir. Se detecta mediante los bytes de firma; guardar con una compresión incorrecta es una causa frecuente de que un mundo editado no cargue.
Un archivo mínimo, byte por byte
El ejemplo hello_world.nbt: un compuesto raíz llamado hello world que contiene una etiqueta string name con valor Bananrama. En la codificación big-endian de Java:
0A TAG_Compound
00 0B 68 65 6C 6C 6F 20 77 6F 72 6C 64 name length 11, "hello world"
08 TAG_String
00 04 6E 61 6D 65 name length 4, "name"
00 09 42 61 6E 61 6E 72 61 6D 61 value length 9, "Bananrama"
00 TAG_End
El mismo documento en little-endian de Bedrock solo cambia el orden de los dos campos de longitud: 0B 00 en vez de 00 0B. En NBT de red de Bedrock, las longitudes son bytes varint únicos, 0B y 04, sin relleno. El editor detecta automáticamente cualquiera de los tres.
SNBT
SNBT es NBT escrito como texto y es lo que consumen los comandos: /data merge entity @s {Invulnerable:1b}. Los sufijos conservan el tipo: b byte, s short, L long, f float, d double y ninguno para int; los arreglos tipados se escriben [B;…], [I;…], [L;…]. El editor exporta cualquier archivo a SNBT para comparar versiones como texto normal.
Preguntas frecuentes
¿Existe una especificación oficial de NBT?
No hay una especificación formal de Mojang. Notch documentó el formato en 2010 y la comunidad lo mantiene desde entonces; los id y la estructura de esta página coinciden con los que el juego usa actualmente.
¿Por qué Bedrock usa little-endian?
El motor de Bedrock está escrito en C++ y se dirige a hardware little-endian, por lo que guarda los valores en orden nativo. La serialización de Java es big-endian por el contrato de Java DataOutput.
¿Qué es la codificación varint zigzag?
Es una forma de guardar enteros con pocos bytes y mantener cortos los negativos: el signo se integra en el bit inferior, así −1 se codifica como 1 y 1 como 2. El protocolo Bedrock la usa para ints y longs.
¿Puede una TAG_List contener tipos distintos?
No. Una lista declara un único tipo de elemento y todas sus entradas deben coincidir. Para datos mixtos se necesita una lista de compuestos.
¿Cuál es la longitud máxima de una cadena?
65535 bytes en las codificaciones fijas porque la longitud es un short sin signo. La codificación de red varint no tiene un límite práctico.