ProtocolLib has, for the most part, moved over to Spigot! If you need support, head over there!

Certain tasks are impossible to perform with the standard Bukkit API, and may require working with and even modify Minecraft directly. A common technique is to modify incoming and outgoing packets, or inject custom packets into the stream. This is quite cumbersome to do, however, and most implementations will break as soon as a new version of Minecraft has been released, mostly due to obfuscation.

Critically, different plugins that use this approach may hook into the same classes, with unpredictable outcomes. More than often this causes plugins to crash, but it may also lead to more subtle bugs.

Development builds of ProtocolLib can be found here:
Older development builds can be found here:
These builds have not been approved by the BukkitDev staff. Use them at your own risk.


Please create a issue with as much information as possible if you experience a problem that has not already been reported. Comments with a huge stack trace will be deleted.

If you need help with the API, please use the Spigot discussion forum. If your question cannot be made public for whatever reason (including security bugs), send me a personal message instead.

For server operators

Just download ProtocolLib from the link above. It doesn't do anything on its own, it simply allows other plugins to function.


  • Why do I get FieldAccessExceptions when I try to read or write from packets?

The reason for these exceptions is because ProtocolLib is not using the packet format as described on the Wiki, it's using the in-memory representation of these packets. Often, the in-memory representation will use integers instead of shorts and bytes, and store more complex objects (like ItemStacks) directly.

You can figure out the in-memory representation from the Minecraft source code, or just use PacketWrapper where I've done all that work for you.


Source code for a bunch of example programs that use ProtocolLib can be found at this thread on the main support forum.

You may also be interested in PacketWrapper, a library that makes it possible to modify a packet without having to decompile the Minecraft source code.

Finally, for the more advanced users who want to use ProtocolLib if present, but still fall back on their own packet listening system, I recommend taking a look at this thread. I explain where and how to inject code into CraftBukkit in order to intercept sent and received packets yourself.

Maven repository

If you're using Maven, you'll be able to automatically download the JAR, JavaDoc and associated sources from the following repository:

  <!-- And so on -->

This repository contains ProtocolLib, TagHelper and BlockPatcher. You can add any of them as a dependency like so:

  <!-- And so on -->



Main administrative command. Supports the following sub-commands:

  • config: Reload the configuration file.
  • check: Check for new versions on BukkitDev.
  • update: Check for new versions and automatically download the JAR. The server must be restarted for this to take effect.
  • timings: Toggle measuring the amount of CPU time spent by each plugin. See here for more information.
  • listeners: Display what plugins are using ProtocolLib, and the packet types they are intercepting.

All of these commands require the permission protocol.admin.


/protocol update


Add or remove a debug packet listener. This is useful for plugin authors who just wants to see when a packet is sent, and with what content.

Sub commands:

  • add: Add a packet listener with a given packet ID.
  • remove: Remove one or every packet listener with the given packet IDs.
  • names: Print the name of every given packet ID.

Parameters (in order):

  1. Connection side: Either client or server.
  2. Multiple ID ranges: Can be a single packet ID like 14, or a range like 10 - 15. Defaults to 0 - 255 if not specified.
  3. Detailed: If TRUE, prints the full packet content.


/packet add client 10-13 true

For 3.0.0 and above, you should specify the protocol, sender and name instead:

/packet add play server chat true

In 3.4.0-SNAPSHOT and above, you can also display the packet before its modified by any packet listeners:

/packet add play server chat compare

Remove all listeners:

/packet remove client
/packet remove server

Note that this command should rarely be used on a production server. Listening to too many packets may crash the server.


The filter system (introduced in 2.4.1) uses the built in JavaScript interpreter in JVM 6 (Rhino) to extend the packet command with filtering capabilities - it is now possible to, say, only print entity metadata packet events (packet add server 40) for a given entity ID:

> packet add server 40 true
Added listener ListeningWhitelist{priority=MONITOR, packets=[40]}
> filter add entity_filter 40
Enter filter program ('}' to complete or CANCEL):
function(event, packet) {
>   return packet.a == 1000; 
Added filter entity_filter.

This should be much more convenient than having to compile a test plugin and reload the whole server. Note that this feature is disabled by default for security reasons. To enable it, add "debug: true" to config.yml.


A small set of configuration options are available:

Global section



auto updater.notifytrueInform any player with the permission when a new version of ProtocolLib is out.
auto updater.downloadtrueAutomatically download and install the newest version of ProtocolLib. The installation will take effect when the server restarts.
auto updater.delay43200The number of seconds between each check for a new update.
auto updater.last0This simply records the last time (in seconds since 01.01.1970) an update check was performed. Set it to 0 to force a new update check.
metricstrueIf TRUE, ProtocolLib will publish anonymous usage data to Set it to FALSE to opt-out.
background compilertrueIf TRUE, ProtocolLib will try and improve performance by replacing reflection with compiled code on-the-fly.
ignore version checkNoneForce ProtocolLib to start for a specified Minecraft version, even if it is incompatible.
suppressed reportsNoneIf any error or warning report is present in this list, they will not appear in the console or the log.

For more information, take a look at the default configuration file.

Tutorial for developers

See this page for more information.


One of the main goals of this project was to achieve maximum compatibility with CraftBukkit. And the end result is quite good - in tests I successfully ran an unmodified ProtocolLib on CraftBukkit 1.8.0, and it should be resilient against future changes. It's likely that I won't have to update ProtocolLib for anything but bug and performance fixes.

How is this possible? It all comes down to reflection in the end. Essentially, no name is hard coded - every field, method and class is deduced by looking at field types, package names or parameter types. It's remarkably consistent across different versions.

Plugins that appear to be compatible

Plugins known to be compatible

  • SpoutPlugin

Plugins using ProtocolLib

Inactive projects

Please let me know if you want me to add your plugin to this list. :)


This plugin uses MCStats to generate and publish anonymous aggregate usage statistics, but you can easily opt-out by setting metrics in config.yml to false.

If enabled, the following is sent every ten minutes:

  • Metrics revision version (currently 6).
  • Server's GUID
  • Players currently online (not max player count)
  • Server version string (the same version string you see in /version)
  • Current version of ProtocolLib
  • The name of every plugin that registers a packet listener in ProtocolLib.


If ProtocolLib has made your life significantly easier or you're feeling particularly generous, consider donating! It's a great way to support the many hours I've spent maintaining this plugin and keeps me motivated. Don't donate if you can't afford it.


I would like to thank everyone who has donated to ProtocoLib on BukkitDev. I really appreciate it. :)


ProtocolLib Statistics

Note: Create an issue if you're having problems. I generally don't check the BukkitDev comments.

You must login to post a comment. Don't have an account? Register to get one!

  • Avatar of libraryaddict libraryaddict Nov 03, 2013 at 00:20 UTC - 0 likes

    @Quantum64: Go

    That's in packet 40 entity metadata.

    I'm not sure what that is that you are refering to, but I send the mob spawn packet, then send a packet 40 entity metadata to set flags on the spawned mob.

    Last edited Nov 03, 2013 by libraryaddict


  • Avatar of Quantum64 Quantum64 Nov 02, 2013 at 21:15 UTC - 0 likes

    Quick question regarding Packet18SpawnMob. How do you set the entity metadata (Mob name, sheep color, health, etc..) I know it has something to do with the WrappedDataWatcher, but i'm not sure how to set the values or metadata type for it.

    Also, i'm using packet wrapper, so it's in the setMetedata method, i'm just not sure how to use WrappedDataWatcher, as I said.

  • Avatar of aadnk aadnk Nov 02, 2013 at 21:07 UTC - 0 likes

    @zaino60: Go

    I have a partial update here that should enable Lib's Disguises to work.

    Ordinarily, I would direct you to download the latest developer build from my Jenkins server, but it's been having issues today. I apologize for the inconvenience. You may use my FTP-server in the meantime.

    These builds come with the usual disclaimer - they have not been approved by the BukkitDev staff, and you use them at your own risk.

    EDIT: I've set up a new Jenkins server.

    Last edited Nov 03, 2013 by aadnk
  • Avatar of zaino60 zaino60 Nov 02, 2013 at 16:21 UTC - 0 likes

    Please Update to 1.7 so I can use Lib's Disguises!! Thank you! PD: the Experimental Spigot 1.7 compatible version is also to buggy!

    Last edited Nov 02, 2013 by zaino60

  • Avatar of libraryaddict libraryaddict Nov 02, 2013 at 04:14 UTC - 0 likes

    Welp. You both misunderstood me.

  • Avatar of Quantum64 Quantum64 Nov 02, 2013 at 01:48 UTC - 0 likes

    @lenis0012: Go

    I wouldn't be so sure, apparently it's so cleverly coded that it can use reflections to get updated Packet fields and ids.

    Edit: On this very page it says: "How is this possible? It all comes down to reflection in the end. Essentially, no name is hard coded - every field, method and class is deduced by looking at field types, package names or parameter types. It's remarkably consistent across different versions."

    Last edited Nov 02, 2013 by Quantum64
  • Avatar of lenis0012 lenis0012 Nov 02, 2013 at 00:12 UTC - 0 likes

    @libraryaddict: Go

    Not really, protocol changes very very often. Big chance that it will break on 1.7.2, im very sure actualy.

    There is no way to gest whats there in the future, so you cant prepare for it. The good thinkg about ProtocolLib is that it uses numbers instead of field names. Wich can make it easier for the plugin itself not the break, but for the plugins wich use it still can easily break.

    We will see how 1.7 goes, im exited.

    Follow me on twitter for updates: @lenis0012

  • Avatar of Quantum64 Quantum64 Nov 01, 2013 at 23:36 UTC - 0 likes

    Dynamically extending classes is way over my head as far as java goes, but I really like ProtocolLib, and I can tell how much time and work you have put into the making of it. Keep up the great work, because this is an awesome resource for developers to have!

  • Avatar of libraryaddict libraryaddict Nov 01, 2013 at 23:26 UTC - 1 like

    @aadnk: Go

    That's the crazy thing about this plugin. Its always compatible.

  • Avatar of aadnk aadnk Nov 01, 2013 at 22:59 UTC - 0 likes

    @Quantum64: Go

    Yeah, I use reflection extensively, almost to the point of abusing it. But it has enabled ProtocolLib to stay compatible with every version from today and until Beta 1.0 - in fact, I only really hit a snag when the versioned packages were introduced, and I had to slightly break the API by changing the type of PacketContainer.getHandle() from NMS.Packet to Object.

    You can see how I inject packets into the stream here. Retrieving a reference to the method itself requires a lot of crazy reflection, as ProtocolLib is also compatible with MCPC (where sendPacket is called addToSendQueue) and other Forge-enabled Bukkit servers. Naturally, it is slower and more complicated than the direct approach, but with a modern JVM the performance is acceptable.

    But reflection isn't really a hack in my book. Especially if you compare it to CGLib and ASM, which I use to dynamically extend classes and interfaces, and generate byte code on-the-fly to directly access packet fields without reflection. That's a hack. :P

    Last edited Nov 01, 2013 by aadnk