Minecraft 1.8.9
Packet Reference
Complete documentation of all 105 packets across 4 protocol states with fields, wire encoding, MCP class references, and real-world implementation cases from 30+ verified 1.8.9 clients.
How the Minecraft Protocol Works
Minecraft Java Edition communicates between client and server using TCP packets serialized through Netty. Every packet is an instance of net.minecraft.network.Packet and carries structured binary data — VarInts, strings, positions, item stacks, NBT compounds — written into a PacketBuffer (Netty's ByteBuf wrapper).
The protocol is divided into four states (EnumConnectionState), each with its own packet ID registry and direction (EnumPacketDirection.SERVERBOUND / CLIENTBOUND):
Handshaking
1 packet. The very first packet sent by the client. Contains protocol version (47 for 1.8.9), server address, port, and the requested next state (1=Status, 2=Login). C00Handshake. Serverbound only.
Status
4 packets. Used by the server list ping screen. Client sends server query request → server responds with JSON MOTD/players/favicon. Then client pings with a timestamp → server echoes it back. Fully stateless.
Login
6 packets. Authentication flow. Client sends username → server sends encryption request with public key → client responds with encrypted shared secret → server confirms login success and optionally enables zlib compression.
Play
94 packets. The main game state. Everything happens here — movement, chat, combat, inventory, world loading, entity management, scoreboards, plugin messages. 23 serverbound (client→server) + 71 clientbound (server→client).
Packet Class Structure (MCP)
In MCP (Minecraft Coder Pack) deobfuscated source, packet classes follow a strict naming convention:
- Serverbound play:
net.minecraft.network.play.client.CNNPacketName — e.g.C00PacketKeepAlive,C03PacketPlayer - Clientbound play:
net.minecraft.network.play.server.SNNPacketName — e.g.S08PacketPlayerPosLook,S02PacketChat - Login/Status/Handshake: similarly under
login.client,login.server,status.client, etc. - The hex ID (
0x00–0x49) is assigned by registration order inEnumConnectionState. Packets are registered per-direction within each state.
Each packet class has a readPacketData(PacketBuffer) method for deserialization and writePacketData(PacketBuffer) for serialization. A paired handler interface (e.g. INetHandlerPlayServer for serverbound, INetHandlerPlayClient for clientbound) defines a processPacketName(Packet) method that the server/client calls when the packet arrives.
Wire Encoding
Minecraft uses several custom wire types beyond standard Java primitives:
- VarInt / VarLong — Variable-length integer encoding. Smaller numbers use fewer bytes. Used for packet IDs, entity IDs, array lengths.
- String — Length-prefixed with a VarInt, encoded in UTF-8. Max 32767 chars in most cases.
- Position (BlockPos) — Packed into a single 64-bit long:
((x & 0x3FFFFFF) << 38) | ((y & 0xFFF) << 26) | (z & 0x3FFFFFF). - Fixed-point coordinates — Entity positions are sent as
floor(value * 32)for blocks orfloor(value * 8000)for velocity. Divided back on the receiving side. - Angle encoding — Yaw/pitch are compressed to single bytes:
floor(angle * 256 / 360). - ItemStack (Slot) — Serialized as: block/item ID (short), count (byte), damage (short), optional NBT tag compound.
- Chat Component (IChatComponent) — JSON-serialized tree of ChatComponentText, ChatComponentTranslation, ChatComponentStyle, etc.
- DataWatcher (Metadata) — Stream of type-prefixed key-value pairs for entity state. Each entry has a type byte and value.
Data sourced from MCP (Minecraft Coder Pack), minecraft.wiki, and deobfuscated source. Implementation cases compiled from 30+ verified 1.8.9 clients.
Minecraft is a trademark of Mojang AB. This is not affiliated with Mojang or Microsoft.