Minecraft schematic and NBT viewer

What it shows

• A summary: the format and its version, the Minecraft release the file was saved in (from its data version: 2586 is Java 1.16.5, 3465 is 1.20.1, 3953 is 1.21), the size as width × height × length, how many blocks are not air and of how many kinds, and the name, author, description and dates the file carries. A .litematic also shows its regions, each with its position, size, palette and how its block states are packed, and its preview picture if it saved one.
• The materials list: every block with its count, biggest first, with the same count as stacks of 64 and as shulker boxes (27 stacks, 1,728 blocks). Block states are merged per block (all oak_stairs together) with a switch to split them (facing=east,half=bottom on its own row). Air is left out. Save as CSV opens in any spreadsheet.
• A layer view: one horizontal slice at a time, seen from above, every block a flat square of colour. A slider moves through the height; pointing at or tapping a square names its block and state; Save layer as PNG keeps the slice.
• Entities and block entities, counted by id: the chests, signs, banners and spawners in it, and the mobs, armor stands and item frames.
• The NBT tree: every tag with its type (Byte, Short, Int, Long, Float, Double, String, List, Compound and the three arrays), opened a level at a time, with a search over names and values. Long arrays show their first 256 values and how many follow.
• A level.dat (Java or Bedrock): the world name, seed, game mode, difficulty, hardcore, whether cheats are on, the version, spawn point and when it was last played.

Stacks and shulker boxes, worked out

A stack holds 64 blocks and a shulker box 27 stacks, so 1,728 blocks. 1,000 stone bricks are 15 stacks and 40 more (15 × 64 = 960), or 0.58 of a shulker box. The line above the table counts inventory slots the way you fill them: every kind starts a new slot, so 70 oak planks and 3 glass take three slots, not two. Not every item stacks to 64: signs, banners and ender pearls stop at 16, beds at 1. And a placed block is not always its item: a wall torch is a torch, a door is two blocks but one item, a double slab is two slabs, and water, lava and fire are not items at all. Check those rows before you go gathering.

The six formats

• .litematic (Litematica mod): gzip NBT with one or more named regions. A region whose size is negative extends back from its position; the page puts every region in one enclosing box. Each region keeps a palette and a BlockStates long array holding a palette number per block, using as many bits as the palette needs (at least 2).
• .schem (Sponge Schematic Specification, written by WorldEdit 7 and FAWE): v1 and v2 keep a Palette of block-state strings and a BlockData byte array of varints; v3 moves both into a Blocks compound. Palette numbers 0 to 127 take one byte, 128 to 16,383 two.
• .schematic (MCEdit, old WorldEdit, Schematica): one byte per block in Blocks, a 4-bit data value in Data and, for ids above 255, an AddBlocks nibble array. These are pre-1.13 numeric ids; the page names ids 0 to 255 as Minecraft 1.12 called them (minecraft:wool, with the colour in the data value) from a table written for this site, and shows any other id as a number. A Schematica file that carries its own id table is named from that table.
• .nbt (structure block, Java Edition): a palette and a list of blocks, each with its position. Cells with no entry are structure void; the layer view leaves them blank. Files with several palettes (shipwrecks have random variants) show the first.
• .mcstructure (Bedrock Edition): little-endian NBT, not compressed. Blocks are stored x first, then y, then z, with z changing fastest; a second layer holds water for waterlogged blocks and is counted on its own.
• level.dat: Java's is gzip NBT with everything under Data (last played in milliseconds); Bedrock's is little-endian NBT after an 8-byte header (a storage version and the length), with last played in seconds.

Why block states sometimes read as garbage

Litematica packs its palette numbers back to back, so a value can start near the end of one 64-bit long and finish in the next. Minecraft did the same in chunks until 1.16, then switched to never splitting a value: each long holds as many whole values as fit and the leftover bits are padding. A reader that assumes the wrong one gets the first few hundred blocks right and the rest scrambled. Worked example: a 6 × 5 × 8 region with an 18-entry palette needs 5 bits a block (16 < 18 ≤ 32). Its 240 blocks take 1,200 bits, 19 longs packed back to back; padded, 12 values fit each long (60 bits, 4 spare) and it takes 20. The page tells the two apart by that length and names the packing it used for each region. When the bits divide 64 exactly (2, 4, 8, 16) the two layouts are the same.

What it cannot do

• No 3D view and no textures. It draws one layer at a time as flat colours from this site’s own table, chosen to tell blocks apart. They are not the game’s textures or colours, and similar blocks (stairs and slabs of the same wood) share one.
• No region files or whole worlds. .mca and .mcr region files, a world folder and Bedrock’s LevelDB database are not read. A level.dat on its own is.
• No editing. It does not change, convert or save a schematic. It cannot turn a .schematic into a .litematic or a Java file into a Bedrock one.
• Entities and block entities are listed, not drawn. Item frames, armor stands, paintings and minecarts do not appear in the layer view; their data is in the NBT tree.
• Modded blocks have no colour of their own. A block outside the table gets a steady made-up colour from its name, and the hover still names it.
• Very large builds depend on memory. Up to 48 million cells are laid out (four bytes each); a bigger file shows its summary and NBT tree only. A phone may run out of memory sooner.