A single corrupted or stuck character can ruin a player’s experience on an otherwise healthy Project Zomboid server. Maybe their save broke during a crash, they fell through the world after a mod update, or an item glitch left them permanently encumbered or stuck inside a wall. The good news: you can reset that one character to a clean slate without wiping the world, the map changes, or anyone else’s progress. The bad news: doing it carelessly can destroy a live database that holds every player on your server. This guide walks through the safe, source-verified procedure step by step, with backups front and center.
Everything here applies to Build 41 (B41.78), the current stable branch that most dedicated servers still run. The save layout and player-database structure are long-standing and carry forward into the Build 42 unstable branch as well (B42 has been the opt-in beta since December 2024, with multiplayer only rejoining the unstable branch around December 2025). Where a detail could differ by build, we flag it. If you run a managed box, you can apply the same logic through your dedicated Project Zomboid hosting file manager rather than a local Windows path.
Where Project Zomboid actually stores your characters
Before you touch anything, you need to understand where the data lives. A Project Zomboid dedicated server writes everything into the user Zomboid/ folder. On a Windows host that is C:\Users\; on Linux it is under the home directory of the account running the server. Inside that folder you have three things that matter here:
Server/— the configuration files (servertest.ini,servertest_SandboxVars.lua,servertest_spawnregions.lua). Default server name isservertest, so the files are named accordingly.Saves/— the actual worlds, including all map chunks and the player database.Logs/— timestamped logs rotated out on restart.
Multiplayer worlds specifically live in Zomboid/Saves/Multiplayer/. On Windows that resolves to:
C:\Users\\Zomboid\Saves\Multiplayer\\ Inside that server folder sits the file that holds every character: players.db. This is a standard SQLite database. The map chunks, building states, and zombie data are stored in separate files and folders — which is exactly why a per-character reset is possible. You can surgically remove one player’s record while leaving the world completely intact.
The NetworkPlayers table
Open players.db and you will find a table named NetworkPlayers. This table contains one row per character on the server. Each row stores that character’s position, health, inventory, traits, skill XP, and the body/world state that makes them feel “broken” when something corrupts. Reset a character and you are simply deleting their single row. The next time that player connects, the server has no record of them and walks them through fresh character creation — new spawn, blank skills, empty pockets, clean slate.
Because every player on the server shares this one file, a mistake here is not a “your character” mistake — it is a “the whole server” mistake. That is why the procedure below is built around backups and a stopped server, not convenience.
Before you start: the three non-negotiable rules
- Stop the server first. Editing a live SQLite database while the server is running can corrupt it. The game may also overwrite your edit on its next save tick, so your changes would not stick anyway.
- Back up
players.dbbefore you open it. Copy the file somewhere safe and rename it (for exampleplayers.db.bak). If anything goes wrong, you restore the backup and you have lost nothing. - Understand this is destructive. Deleting a row zeroes that character permanently. There is no “undo the break and keep my skills” option — the row either exists in its current (broken) state or it does not exist at all. You cannot recover the pre-break version.
Set expectations with the affected player up front: their character is gone either way (it is already broken), and a reset gives them a working character back rather than a glitched one. That framing usually lands fine.
Step-by-step: reset one broken character safely
Step 1 — Stop the server
Shut the server down cleanly. If you have console access, issue a final save and quit so the database is flushed and closed:
save
quitOn a managed host, use the panel’s Stop button and wait until the status confirms the server is fully offline before continuing. Do not just kick the player — the server process must be down.
Step 2 — Locate and back up players.db
Navigate to your multiplayer save folder:
C:\Users\\Zomboid\Saves\Multiplayer\\players.db Copy players.db to a safe location and keep the original untouched as your restore point. A simple, dated copy in the same folder is fine:
copy players.db players.db.2026-06-15.bakDo not skip this. It is the difference between a five-minute fix and a wiped server. If you are on a remote host, download a copy to your local machine as well.
Step 3 — Open the database in DB Browser for SQLite
Download and install DB Browser for SQLite (a free, open-source tool). Launch it, choose Open Database, and select your players.db file. Switch to the Browse Data tab, then in the table dropdown select NetworkPlayers. You will see one row per character, with columns for the username and character data.
Step 4 — Find the broken player’s row
Identify the row belonging to the affected player — usually by matching the username column to their account name. Take a moment to confirm you have the right row. The whole point of this method is precision: you are removing one character, not running a server wipe.
Step 5 — Delete just that one row and write changes
Select the entire row for the broken character (click the row header so the full row is highlighted, not just one cell), then use DB Browser’s delete-record button to remove it. Critically, click Write Changes to commit the edit to the file — if you close without writing, nothing is saved. Then replace the live players.db with this edited file if you were working on a copy.
That is the entire destructive action: one row, gone, committed. The world chunks, every other player’s row, faction data, and safehouse claims are all untouched because they live outside that single record.
Step 6 — Restart and verify
Start the server again. When the affected player reconnects, the server finds no record for them and presents fresh character creation. They pick traits, choose a spawn region, and drop into the same living world everyone else is in. If something looks wrong, stop the server and restore your players.db.bak — this is exactly the scenario that backup exists for.
| What you are doing | What it affects | What it does NOT affect |
|---|---|---|
Delete one row in NetworkPlayers | That single character (skills, inventory, position, body state) | The world, map changes, other players, safehouses, faction data |
Delete the entire players.db | Every character on the server (full character wipe) | The world map itself (still a heavy, rarely-wanted action) |
Delete the whole | Everything — full server reset | Your config files in Server/ |
Why the per-row method beats deleting files
You will find old forum advice that says “just delete the save folder” or “delete players.db.” Those are sledgehammers. Deleting players.db entirely wipes all characters; deleting the save folder wipes the world too. The single-row deletion in NetworkPlayers is the only approach that surgically resets one person while leaving a multiplayer community’s hard-won progress intact. On a server with 16 or 32 active survivors, that distinction is everything.
If you are managing this on a hosted box, the same files are available through your control panel’s file manager and SFTP. Our Project Zomboid setup documentation covers the folder layout and how to reach Saves/Multiplayer/ on a managed instance, which makes the backup-and-edit cycle straightforward even without local Windows access.
Common causes of a “broken” character (and which ones a reset fixes)
Not every problem needs a database edit. Before you reset, it is worth a quick diagnosis, because the cause tells you whether a reset is even the right tool:
- Mod-induced corruption. A mod that was updated or removed mid-save can leave a character referencing items or scripts that no longer exist. This is the classic reset candidate. Check your
*_DebugLog-server.txtinZomboid/Logs/for Lua errors — a mod ID near the stack trace usually points at the culprit. Our guide to reading Project Zomboid server logs walks through which file to open for which symptom. - Stuck in geometry / fell through the world. Sometimes an admin
/teleporttoor a/godmodetoggle frees a player without any database surgery at all — try that first. - Permanent encumbrance or item glitch. If only the inventory is the problem, an admin can sometimes clear it in-game faster than a reset.
- True save corruption. When the character won’t load at all or crashes the client on join, the
NetworkPlayersrow deletion is the reliable fix.
For the in-game options, you’ll need admin access and the right commands. The full toolset — access levels (admin, moderator, overseer, gm, observer), teleporting, item granting, and more — is covered in our Project Zomboid admin commands reference.
Admin commands that can fix a character without a reset
If the character is salvageable, these admin commands (run in in-game chat with a / prefix, or in the server console / RCON without the prefix) often solve the problem more gently than a database edit:
| Command | Use it when |
|---|---|
/teleportto x,y,z | The player is stuck in a wall or under the map — move them to safe coordinates. |
/godmode | The player is trapped mid-attack or in a damage loop — buy them time to escape. |
/additem | A lost or glitched essential item can be re-granted (e.g. Base.Axe). |
/addxp | Restoring skill progress if a partial reset is acceptable to the player. |
/save | Force a world save before and after any intervention. |
Note: the spelling /godmode is the verified form, but if it doesn’t register on your build, check /help godmode for the exact syntax. Run /help at any time for the full list, and /help for a single command’s parameters. If none of these recover the character, fall back to the NetworkPlayers reset above.
A note on Build 41 vs Build 42
The reset procedure is identical on both builds — the save layout (Saves/Multiplayer/), the NetworkPlayers table, and the backup-first workflow all carry forward. What changes between builds is the world, not the player-storage mechanism. In the Build 42 unstable branch (as of mid-2026), Knox County expands westward with new towns like Brandenburg, Ekron, and Irvington, buildings gain procedurally generated basements and more verticality, and crafting is rebuilt from the ground up. None of that alters how you remove a single character’s row.
One critical caveat: Build 42 saves are not compatible with Build 41, and there is no official converter. A world made in one build cannot be opened in the other. So while the reset steps are the same, make sure your backup of players.db stays paired with the build it came from — never try to graft a B42 player database onto a B41 world or vice versa.
Reduce the odds you’ll need this again
- Take regular backups of the whole save folder, not just before edits. A nightly copy of
Saves/Multiplayer/means a corruption event costs you a day at most./ - Be conservative with mid-wipe mod changes. Removing a mod that has placed items into the world or onto characters is the single most common cause of broken saves. If you must change mods, back up first and warn players.
- Keep
PauseEmpty=trueso the world isn’t churning when nobody is online — fewer write events, fewer chances for a bad save during a crash. - Watch your logs. Catching repeated Lua errors early lets you disable a misbehaving mod before it corrupts characters across the server.
If you’re still setting up your server and want the configuration side dialed in before players ever break a character, our walkthrough of the servertest.ini settings explained covers the full file, including whitelist behavior via the Open key and the player-cap and port settings that keep a server stable.
Frequently asked questions
Will resetting one character delete the world or affect other players?
No. The map, building states, zombie data, safehouses, and every other player’s character are stored separately from the single row you delete in the NetworkPlayers table. Removing one row in players.db resets only that one character. The rest of the server is untouched — that is the entire reason this method is preferred over deleting files.
Can I recover the character’s skills and gear after I reset it?
Not from a reset — deleting the row zeroes the character permanently; there is no built-in undo and no way to restore the pre-break state. The only recovery path is your backup. If you copied players.db before editing (and you should have), you can restore that backup to get the character back exactly as it was, broken state included. That is why backing up first is non-negotiable.
Do I really have to stop the server, or can I edit the database live?
Always stop the server. Editing a live SQLite database risks corrupting the entire file — which would affect every player, not just the broken one. On top of that, a running server can overwrite your edit on its next save tick, so the change wouldn’t stick. Stop the server, edit, then restart.
What tool do I use to open players.db?
Use DB Browser for SQLite, a free open-source database editor. Open players.db, go to the Browse Data tab, select the NetworkPlayers table, delete the broken player’s row, and click Write Changes to commit. Any SQLite-capable client works, but DB Browser is the most beginner-friendly for this task.
The player can’t reconnect after the reset — what happened?
First confirm the server fully restarted after your edit. If your server runs with Open=false (whitelist-only), the account still exists even though the character is gone, so the player should be able to rejoin and create a fresh character. If they truly cannot connect, restore your players.db backup, restart, and re-check that you deleted the correct single row rather than accidentally affecting another record. Our whitelist setup guide explains how the Open key and accounts interact.
Is the reset process different on Build 42?
No — the save path, the players.db file, the NetworkPlayers table, and the backup-first workflow are the same in the Build 42 unstable branch as in Build 41. Just remember that B42 and B41 saves are not cross-compatible and there is no official converter, so keep each backup matched to its build.
Reset done right, a broken character is a five-minute fix that nobody else even notices. Reset done carelessly, it’s a server-wide wipe. The whole difference is two habits: stop the server, and back up players.db before you delete a single row.
Ready to play?
Run your own Project Zomboid server with XGamingServer
Spin up an always-on Project Zomboid server your friends can join in minutes — no port-forwarding, no tech headaches.
