Protocol versions and data versions, and what each is for

Two numbers, two jobs

Both identify a Minecraft version. They answer different questions and are not interchangeable, and mixing them up produces bugs that look like nothing else.

	Protocol version	Data version
Answers	Can these two connect?	Which version wrote this save?
Lives in	The handshake packet	level.dat, chunk data, item NBT
Repeats across versions	Yes	No
Increases monotonically	No	Yes
Safe to sort by	Never	Yes, from 1.9 onward
Exists before 1.9	Yes	No

Protocol version

The number a client and a server exchange when they first talk. If they differ, the connection is refused before anything else happens.

Two properties make it useless for anything except that one question:

It repeats. Mojang only increments it when the network format actually changes, so consecutive releases sometimes share one. 1.21.7 and 1.21.8 are both 772, which is why a 1.21.7 client joins a 1.21.8 server without complaint.

Snapshots use a separate range. Snapshot protocol numbers are offset by a very large constant so they cannot collide with release protocols. Sorting a mixed list by protocol throws every snapshot to one end of it.

So: use it to answer "can these connect", and never to answer "which is newer". The connection checker does exactly the first, and every version page here lists its protocol number and the other versions that share it.

Data version

A plain integer, incremented on every version including snapshots, from 1.9 onward.

It is written into save data, which is what makes it useful: level.dat carries a DataVersion field naming the version that last wrote the world, and chunks and item NBT carry it too. That is how the game knows what to convert on load, and how a tool knows what it is reading without guessing from a folder name.

It increases monotonically across the whole history, snapshots included, which makes it the best numeric key for ordering two versions when you have both.

Its two limits:

• Nothing below 1.9 has one. Anything older needs the manifest order instead.
• It is not in the version manifest. You have to fetch each version's detail document to read it, which is one request per version. Ingest it once and store it.

Which to use when

"Can my client join that server?" Protocol version. Nothing else answers this.

"Which of these two versions is newer?" Data version if both have one, otherwise the order Mojang publishes in its own version manifest. Never protocol, never the version string. Which version is newer covers the sorting problem properly, including why string comparison broke in 2026.

"What wrote this world?" Data version, from level.dat.

"Is this pack compatible?" Neither. Packs use their own pack_format sequence, which is a third unrelated number. See resource pack format numbers.

Storing both

If you are building anything that tracks Minecraft versions, store three fields and keep them apart:

sortIndex        position in Mojang's manifest, assigned at ingest, the ordering key
protocolVersion  for connection questions only, nullable, repeats
dataVersion      for save questions and as a numeric ordering key, nullable below 1.9

sortIndex is the one that saves you. It is derived once from the manifest's own chronological order, covers every version including the pre-1.9 ones and the April Fools releases, and never needs the version name to be parsed. Both other fields then get to be what they are, facts about a version rather than a way to order them.

Every page on this site orders by sortIndex for exactly that reason, and shows the other two as facts about the version rather than as anything you should sort on.