Guidefor developers5 min read
Minecraft protocol versions: full list and snapshot quirk
Every Java Edition protocol number in one ordered table, what a matching number does and does not guarantee, and why snapshot numbers set the high bit.
What the protocol number is for
The protocol version is a single integer sent in the first packet of a connection. The client states the number it speaks, the server compares it to its own, and if they differ the connection is closed with a version mismatch before login begins. It exists because the wire format changes constantly and there is no negotiation step: either both ends agree on the packet layout or they cannot talk at all.
The number is not derived from the version string. It is assigned by Mojang, it increments only when the wire format actually changes, and it is the only value that decides whether a handshake succeeds. Of the 903 Java Edition versions on this site, 777 carry a protocol number. The rest predate the field.
Protocol numbers for the calendar releases
| Protocol | Versions | Released | Java |
|---|---|---|---|
| 776 | 26.2 | 16 June 2026 | 25 |
| 775 | 26.1, 26.1.1, 26.1.2 | 24 March to 9 April 2026 | 25 |
The switch to calendar versioning did not reset the counter. 26.1 continued from 774, which was the last 1.x release, 1.21.11. That is deliberate: the protocol number is a wire format identifier and the wire format did not restart, only the naming did. If you are wondering where 1.22 went, see why 1.22 became 26.1.
Protocol numbers across the 1.x era
Two patterns are worth reading out of the table below before you use it.
First, a bump is not guaranteed per release. Patch releases that change no packets keep the number, which is why 1.21.7 and 1.21.8 both speak 772 and interoperate freely in both directions.
Second, the number is not continuous. It jumps from 578 at 1.15.2 to 735 at 1.16, and from 736 at 1.16.1 to 751 at 1.16.2. The reason is that snapshots used to consume numbers from the same space as releases. Development builds between two releases each took a number, so by the time the release shipped the counter had moved a long way. Mojang fixed this in November 2020, which is where the next section starts.
Why snapshot protocol numbers are enormous
From 20w45a, published 4 November 2020, snapshots stopped sharing the release number space. Instead they set bit 30 of the integer and count upward from there:
0x40000000 = 1073741824 the base
1073741829 = base + 5 20w45a
1073742151 = base + 327 26.3-snapshot-5
Subtract 1073741824 and you get a plain sequence number for the snapshot, counted from that November 2020 starting point. The current snapshot line, 26.3-snapshot-1 through 26.3-snapshot-5, sits at 1073742147 through 1073742151.
This is why a naive integer comparison puts every snapshot above every release. If you are ordering versions, do not sort on the protocol number. Sort on release order, which is what sortIndex on this site does, and treat protocol as an attribute of the version rather than a rank.
What a matching protocol does not guarantee
A matching protocol number gets you past the handshake. It does not get you into the world.
- Assets are separate. A client on the same protocol but a different version can be missing block models, sounds or translations added in a later patch. It connects and then renders wrongly.
- Server software has its own opinion. Paper, Purpur and the proxies check the Minecraft version they were built for, not just the protocol number, and will refuse a client the vanilla server would have accepted.
- Plugins can enforce more. Anything that inspects the client brand or the exact version string can reject a connection the protocol layer allowed.
- Data version is a different check. World and chunk format compatibility is decided by the data version, not the protocol. 26.2 speaks protocol 776 and writes data version 4903, and those two numbers answer different questions.
The correct reading of a protocol match is narrow: these two ends will not be disconnected for a version mismatch. Everything after that is a separate question.
Letting older clients connect anyway
Multi-version support is not a vanilla feature. A vanilla server speaks exactly one protocol number and rejects everything else. Servers that accept a range of client versions are running a translation layer that rewrites packets between the client's protocol and the server's, either as a plugin on the server or on a proxy in front of it.
That translation is best effort. Features added after the client's version cannot be represented in the older packet format, so the layer either approximates them or drops them. It is a viable way to keep a public server reachable, and it is not a substitute for the client and server agreeing on a version.
Full protocol table
Java Edition releases, newest first. Versions sharing a number are grouped on one row.
| Protocol | Releases |
|---|---|
| 776 | 26.2 |
| 775 | 26.1.2, 26.1.1, 26.1 |
| 774 | 1.21.11 |
| 773 | 1.21.10, 1.21.9 |
| 772 | 1.21.8, 1.21.7 |
| 771 | 1.21.6 |
| 770 | 1.21.5 |
| 769 | 1.21.4 |
| 768 | 1.21.3, 1.21.2 |
| 767 | 1.21.1, 1.21 |
| 766 | 1.20.6, 1.20.5 |
| 765 | 1.20.4, 1.20.3 |
| 764 | 1.20.2 |
| 763 | 1.20.1, 1.20 |
| 762 | 1.19.4 |
| 761 | 1.19.3 |
| 760 | 1.19.2, 1.19.1 |
| 759 | 1.19 |
| 758 | 1.18.2 |
| 757 | 1.18.1, 1.18 |
| 756 | 1.17.1 |
| 755 | 1.17 |
| 754 | 1.16.5, 1.16.4 |
| 753 | 1.16.3 |
| 751 | 1.16.2 |
| 736 | 1.16.1 |
| 735 | 1.16 |
| 578 | 1.15.2 |
| 575 | 1.15.1 |
| 573 | 1.15 |
| 498 | 1.14.4 |
| 490 | 1.14.3 |
| 485 | 1.14.2 |
| 480 | 1.14.1 |
| 477 | 1.14 |
| 404 | 1.13.2 |
| 401 | 1.13.1 |
| 393 | 1.13 |
| 340 | 1.12.2 |
| 338 | 1.12.1 |
| 335 | 1.12 |
| 316 | 1.11.2, 1.11.1 |
| 315 | 1.11 |
| 210 | 1.10.2, 1.10.1, 1.10 |
| 110 | 1.9.4, 1.9.3 |
| 109 | 1.9.2 |
| 108 | 1.9.1 |
| 107 | 1.9 |
| 47 | 1.8.9 down to 1.8 |
| 5 | 1.7.10 down to 1.7.6 |
| 4 | 1.7.5 down to 1.7.2 |
Snapshots, pre-releases and release candidates are omitted here because there are hundreds of them and their numbers follow the rule in the section above. Each one is listed on its own page under all Minecraft versions.
What could change
The protocol number for a released version never changes, so every row above is stable. What moves is the top of the table: each new release either takes the next number or reuses the current one, and the snapshot counter advances weekly. Two things are worth rechecking rather than remembering. Whether a new patch release bumped the number, because that decides if existing clients keep working, and which snapshot number the current development line has reached. Both are read from Mojang's version manifest on every sync and shown on the individual version pages, such as 26.2.