Minecraft \"Invalid Player Data\" On Join: What It Means And How To Fix It

The pattern is always the same. Everyone else logs in fine. One person gets:

Connection Lost
Invalid Player Data

And in the server console, some variation of:

Couldn't place player in world
... Loading entity NBT ...
java.lang.NullPointerException

Your world is not broken and your server is fine. One player's saved data is.

What is actually happening

Every player on your server has a .dat file in world/playerdata/. It stores their inventory, position, health, active effects, and anything mods have attached to them.

That file is written in NBT, and it can reference things that only exist because a mod provides them: a modded item in the inventory, a modded status effect, a modded entity the player was riding or holding.

Now change the mod list. Update a mod, remove one, or roll one back. The player's .dat still references something the server can no longer resolve. The server tries to load them, hits a value it cannot parse, throws a NullPointerException, and refuses the connection with "Invalid Player Data".

Which is exactly why it hits one player and not the others: it is whoever happened to have that mod's content on them when the mod list changed. Someone carrying a modded backpack gets locked out; someone who never picked one up does not.

The most common trigger of all: a player disconnects while something modded is active on them (mid-death, with a modded effect running, inside a modded vehicle), and the mod changes before they reconnect.

The two minute fix

This gets them back in immediately.

1. Stop the server. Do not edit world files while it is running.
2. Find the player's UUID. It is in the server log on every join attempt:

   User Authenticator #1/INFO UUID of player Radiant_Blaze is cc4dfd27-8b24-4d82-8d5a-93e97ea05c12
   

   That UUID is the filename.
3. Back up the file first. Copy world/playerdata/<uuid>.dat somewhere safe. Do not skip this, it is the only copy of their inventory.
4. Delete world/playerdata/<uuid>.dat. There is usually a .dat_old next to it. If the corruption is recent, it is worth trying that one first: back up both, delete the .dat, and rename .dat_old to .dat. Sometimes the previous save is intact and you keep their inventory.
5. Start the server. They join as a fresh player: spawn point reset, inventory empty, but able to play.

Be honest with them before you do it. Deleting the file loses their inventory and position.

Why it comes back

Here is the part most guides leave out. Deleting the .dat clears the corrupted data, it does not fix the mod that produced it. If the underlying mod is still misbehaving, the same player can get locked out again the next time they disconnect in the wrong state.

If it happens twice, stop deleting files and find the mod.

Finding the actual culprit

Read the stack trace around the failure. You are looking for a mod name near the Loading entity NBT or player-loading lines. Sometimes it is obvious.

If the trace is all obfuscated (Fabric intermediary names like class_1297 hide mod names), the fastest route is elimination. Real cases from server owners recently came down to a single mod each time:

• A backpack mod, because the contents were serialised onto the player
• A mod adding custom status effects, where the effect no longer existed after an update
• A building mod storing per-player state
• A creature/collection mod attaching data to the player

The common thread: mods that store their own data on the player. Backpacks and inventory extensions, custom effects and abilities, anything with per-player progression, pets or companions that follow you.

Practical method:

1. Note which mods you updated, added, or removed right before it started. That list is almost always where the answer is.
2. Take a copy of the world, remove the suspect mod, and test whether the affected player can join.
3. If you cannot guess, bisect the mod list rather than testing one at a time.
4. Post your log to a paste site rather than reading it in the console, it is far easier to search.

Preventing it

• Back up before every mod change. Not just the world, the whole playerdata folder. This turns a lockout into a thirty second restore.
• Have players log out safely before you change mods. Not mid-combat, not with a modded vehicle or effect active, and ideally somewhere plain.
• Do not remove content mods mid-world. Adding is usually fine. Removing a mod whose items are in players' inventories is the single riskiest change you can make.
• Update one mod at a time on a live server so when something breaks you know what did it.

Not this error?

• Nobody can join and the server never started properly. That is a startup problem, see modded server won't start.
• Server dies with no crash log at all. Memory, see exit code 137 and the OOM killer.
• Everyone gets kicked on join with a proxy involved. Forwarding config, see BungeeCord and Velocity IP forwarding.

Space-Node's modpack hosting gives you file access to world/playerdata/ straight from the panel plus backups you can restore in a click, which is what turns this from a lost evening into a two minute fix.

---

Running a modded server? View Modpack Hosting Plans