Chunk

A chunk is a 16×16-block column containing the full height of the world, used to generate, load, simulate, and save terrain.

Size and coordinates

Property	Size
Width along x	16 blocks
Width along z	16 blocks
Height	128 blocks, y=0–127
Horizontal area	256 block columns
Block positions	32,768, including air

A chunk includes underground terrain and the air above it. The Overworld and Nether use the same chunk dimensions. A biome does not have to end at a chunk border: the Overworld generator reads a biome for each block column.

Chunk coordinates

Each chunk has an x coordinate and a z coordinate. A block's chunk coordinates are its horizontal block coordinates divided by 16, rounded down. Its local x and z coordinates run from 0 to 15. Its y coordinate is unchanged.

Block x or z	Chunk coordinate	Local coordinate
−32 to −17	−2	0 to 15
−16 to −1	−1	0 to 15
0 to 15	0	0 to 15
16 to 31	1	0 to 15
32 to 47	2	0 to 15

For example, the block at (−1, 70, 16) is in chunk (−1, 1), at local position (15, 70, 0).

Chunk borders occur at multiples of 16 along x and z.

Generation and population

A requested chunk is loaded from its save if one exists. Otherwise, the dimension's generator creates it. Reloading a saved chunk restores its blocks rather than rebuilding the terrain from the seed.

Generation and population are separate passes. Generation builds the terrain, surface, and caves. Population adds features such as ores, trees, and dungeons. An unpopulated chunk waits until the neighbouring chunks at +x, +z, and both +x and +z are loaded.

Population chooses feature origins in a 16×16 area offset eight blocks along both horizontal axes from the chunk origin. Features can extend across chunk borders. The saved chunk records whether population has already run, preventing it from being repeated on every load.

Loading and unloading

Loaded, active, and rendered chunks

Term	Meaning
Saved chunk	Chunk data exists on disk. This does not make it run.
Loaded chunk	Its terrain is held in memory. Entities, block entities, and scheduled ticks have their own rules for running.
Active chunk	It is in the player-centred area selected for random block ticks and local weather checks.
Rendered terrain	The client has built geometry to draw it. Visibility does not determine whether the world simulates it.

A chunk can remain loaded without receiving random ticks. A chunk outside the visible terrain can still contain a working furnace or ticking entities.

Singleplayer

Singleplayer loads chunks as the world needs their block data. The initial terrain-loading screen requests a 17×17 square around the player, or the world spawn if there is no player yet. Random ticking and terrain rendering can request further chunks. Reading or changing a block, or looking up a block entity, also loads its chunk if it is absent.

Singleplayer keeps loaded chunks in memory until the player leaves the world or changes dimension. Walking away does not unload them. Leaving the world or changing dimension saves the old world.

Render distance changes the area drawn by the client. It does not change the nine-chunk random-tick radius or evict chunks already loaded. A singleplayer world therefore has no fixed player-centred square containing all of its loaded chunks.

Multiplayer

The dedicated server loads a square of chunks around each player according to view-distance in server.properties.

Setting	Value
Default view distance	10 chunks in each horizontal direction
Accepted view distance	3–15 chunks
Default square per player	21×21 chunks, or 441 chunks

Overlapping player areas share their chunks. The watched area follows the player's movement. Its centre is reconsidered after at least eight blocks of horizontal displacement from the last tracked position and a change of tracked chunk.

When the last player stops watching a chunk, the server queues it for unloading unless it lies in the spawn-retention area. Up to 100 queued chunks are saved and unloaded per world tick. Loading a queued chunk cancels its pending unload.

Respawning loads the destination chunk and checks chunks around a saved bed. Portal searches during dimension travel can also load missing terrain. Ordinary block reads and changes do not load an absent server chunk unless automatic loading is temporarily enabled for spawn selection or portal travel.

The multiplayer client receives terrain from the server. It does not generate missing terrain or save the server's chunks locally. The client's render-distance setting does not replace the server's view distance.

Spawn chunks

On a dedicated server, a chunk is exempt from normal player-triggered unloading when its centre lies within 128 blocks of the world spawn along both x and z. This is a square, not a circular distance test. Depending on the spawn's alignment within its chunk, it includes 16 or 17 chunk centres along each axis.

The same retention test applies in the Overworld and Nether. At startup, the server also loads a 25×25-chunk region around each enabled dimension's spawn. That initial region is larger than the area protected from unloading. Being outside the protected area does not itself queue a chunk; losing its last watching player does.

Spawn retention does not grant random ticks or natural mob spawning without a nearby player. Loaded spawn chunks can still run block entities, scheduled ticks, and entities where their own conditions are met.

Simulation

Random ticks and local weather

Random ticks select chunks within nine chunk coordinates of a player along both horizontal axes. This is a 19×19 square, or 361 chunk coordinates for one player. It is not a circle measured from the player's exact block position. Overlapping areas are processed once per tick.

Each available chunk in that square receives 80 random block selections per game tick. Selections cover the full 16×16×128 volume, including air. Only blocks that use random ticks respond. A particular block is selected about once every 410 ticks on average.

Random-tick growth, such as crop and sapling growth, stops outside this area even if the chunk remains loaded. The same active-chunk area receives the local weather checks for lightning, snow, and freezing water. Player height does not change the horizontal selection area.

A dedicated server with a view distance below nine can have missing chunks inside the selected square. Selecting a coordinate for random ticks does not force that server chunk to load.

Entities

Ordinary entities update only when every chunk intersecting the horizontal square extending 32 blocks from their position is loaded. This covers a 5×5-chunk area centred on their own chunk.

The outer two-chunk-wide border of a rectangular loaded area can be described as lazy chunks: their ordinary entities do not tick. An unloaded hole creates the same effect within two chunk coordinates of it. Block entities and eligible scheduled ticks can still run there.

This check does not use the nine-chunk random-tick radius. Entities in a fully loaded distant area can continue moving or advancing timers. An entity crossing a chunk border is moved into the destination chunk's entity list.

Unloading removes the chunk's entities from the world update list. Their saved state is restored when the chunk loads again. A dropped item's age does not advance while it is not being updated, but walking away in singleplayer does not necessarily stop its timer.

Block entities

Valid block entities in the world's loaded list receive an update every game tick. They do not require the surrounding 5×5 chunks or a place inside the random-tick area. A furnace can continue smelting in a loaded chunk beyond crop-growth range.

An individual block entity can impose additional conditions. A monster spawner needs a player within 16 blocks to run its spawning cycle. Normal chunk unloading invalidates the block entities mapped to the chunk. An orphaned block entity missing from that map can survive unloading.

Scheduled ticks and chunk borders

Scheduled ticks are kept in one world-wide queue, not a queue attached to each chunk. Scheduling a tick requires every chunk intersecting an eight-block neighbourhood of the block to be loaded. The same neighbourhood is checked when the tick becomes due.

The eight-block-wide border inside a loaded area's edge can be described as lazy blocks for scheduled ticks. An unloaded hole creates the same border around itself. Random ticks and block updates can still affect these blocks.

A due tick is removed from the queue even when the surrounding chunks are missing. It is discarded rather than postponed until those chunks return. Scheduled ticks can run beyond random-tick range if their required chunks remain loaded.

A chunk border is not a wall for redstone, fluids, or moving entities. Block updates cross it. Missing neighbouring chunks can prevent scheduled ticks or entity movement from being simulated near a loaded region's edge.

Mob spawning and slime chunks

Natural spawning considers the 17×17 square within eight chunk coordinates of each player. This is separate from both the random-tick area and the server's watched area. A chunk being loaded or retained at spawn is not enough to make natural spawning occur there.

The natural mob cap scales with the size of this eligible area, not the total number of loaded chunks. Existing mobs in all loaded chunks count towards it, including mobs outside the eligible area and in lazy chunks.

A slime chunk is a chunk whose coordinates and world seed pass the slime spawning test. About one chunk in ten qualifies. The designation covers the whole horizontal chunk, but slimes spawn only below y=16. Loading or unloading a chunk does not change its designation.

Saving and data layout

Region files

Chunks are saved in the McRegion format. One .mcr region file covers 32×32 chunks, or 512×512 horizontal blocks. A file contains only the chunks that have actually been saved, not necessarily every chunk in its region.

Dimension	Region-file path inside the world folder
Overworld	region/r.<regionX>.<regionZ>.mcr
Nether	DIM-1/region/r.<regionX>.<regionZ>.mcr

Region coordinates are chunk coordinates divided by 32, rounded down. A chunk's position within its region runs from 0 to 31 on each axis. Negative region coordinates follow the same floor-division rule as negative chunk coordinates.

Chunks are compressed separately inside the region file. Saving one chunk does not regenerate the other chunks in that region.

Chunk contents

Each chunk's saved NBT data is held in a Level compound.

Field	Contents
xPos, zPos	Chunk coordinates
LastUpdate	World time when the chunk was saved
Blocks	32,768 block IDs, one byte per position
Data	16,384 bytes of block metadata, four bits per position
SkyLight	16,384 bytes of saved sky light, four bits per position
BlockLight	16,384 bytes of saved block light, four bits per position
HeightMap	256 bytes, one sky-obstruction height per column
TerrainPopulated	Whether the population pass has run
Entities	Saved entities belonging to the chunk
TileEntities	Saved block entities in the chunk's map

The block array stores y positions consecutively, then z, then x. Entity lookup uses eight vertical groups of 16 blocks within the chunk; these groups are not independently loaded terrain chunks. Biome IDs are not stored in the chunk: the biome manager derives biomes from the world seed and coordinates.

Saving and resuming

Changed blocks, lighting, and block-entity data mark a chunk for saving. Chunks containing entities are also saved periodically even without a changed terrain block. Saving preserves the chunk's state; it does not unload the chunk.

Loading does not replay the ticks that passed while a chunk was unloaded. Crops do not receive missed random ticks, and furnaces do not smelt a backlog merely because their chunk's saved time is old.

Pending scheduled ticks are not included in the chunk's saved data. Closing and reopening the world does not restore that queue. Unloading a chunk also does not create a saved queue of ticks to replay later.

Save suppression

Save suppression is possible in both singleplayer and multiplayer. McRegion silently skips a chunk save when its compressed NBT payload reaches 1,044,475 bytes. The limit applies after compression, not to the uncompressed data or the size of the region file. The loaded chunk continues running.

Previous save	Result after the oversized chunk is discarded and loaded again
Chunk already saved	Its blocks, entities and block entities return to the last successfully saved state.
Chunk never saved	No chunk entry exists on disk; terrain is generated again.

Other chunks and player data can still save. Removing enough data permits later saves to succeed, so the chunk must remain oversized until it is discarded to cause a rollback. Walking away does not discard a chunk in singleplayer; leaving the world or changing dimension does.

Signs

Signs can supply enough data to suppress saving. They accept four lines of up to 15 characters each. Signs can support other signs, allowing dense columns within one chunk. Varied text compresses less than repeated text; there is no fixed number of signs that always suppresses saving. Books have no writable pages or stored page text.

A headless test using the original client classes places 24,000 signs with four full lines of varied ASCII text in one chunk. The compressed payload is 1,453,774 bytes. Saving skips the chunk, and loading restores its previous save. These are automated game-class tests, not a manually built survival-world demonstration.