Database Prefix Changer

Produce the RENAME TABLE statements for a prefix change, along with the row rewrites and the checks to run afterwards.

Runs on your deviceWordPressWorkingNo account needed

What this tool does

Database Prefix Changer writes a SQL script and stops there. It makes no connection to MySQL, holds no credentials, and runs nothing: what you get back is text to read, keep and then execute yourself through phpMyAdmin, Adminer or the mysql client. The script it produces carries its own header — take a dump you have actually tested restoring, put the site in maintenance mode, update wp-config.php in the same window — because those three steps are what separate a prefix change from an outage.

The input is whatever SHOW TABLES gave you. Paste the console output complete with its +---+ borders, pipe characters, the Tables_in_ heading and the trailing row count; all of that is stripped, duplicates are dropped, and anything that is not a bare table name is ignored. Tables that begin with the current prefix are renamed. Tables that do not — another application sharing the database, a staging copy under a different prefix — are listed at the foot of the script as comments so you can see what was deliberately left alone. Leave the box empty and the twelve WordPress core tables are assumed instead, which is right for a bare install and wrong for almost anything with plugins. Leave the new prefix empty and one is generated for you as wp plus four random lowercase letters or digits, drawn from crypto.getRandomValues in this tab.

Renaming the tables is the easy half. WordPress also writes the prefix into the data: wp_user_roles sits in the options table, wp_capabilities and wp_user_level sit in user meta, and a site whose tables move while those rows stay put comes back with every account stripped of its role. So the script includes an UPDATE for each, rebuilding the names with CONCAT and SUBSTRING and matching on a LIKE pattern with the underscore escaped, so wp_ does not quietly match wpx. Multisite per-site options tables are recognised, so wp_2_options gets its own statement when it appears in your list. A SELECT check query follows for each of those two tables when they are in your list, each expected to return no rows, and the new $table_prefix line for wp-config.php is printed as a comment at the end.

The limits are worth reading before you run anything. Each rename is a separate RENAME TABLE statement rather than one multi-table rename, so a failure part-way leaves some tables moved and some not — hence maintenance mode. The two UPDATE statements match on the prefix alone, which means option names and meta keys that merely begin with wp_ without deriving from the prefix are caught with the rest; wp_page_for_privacy_policy is the one people hit, and it needs setting again afterwards. Nothing outside the options and user meta tables is examined, so a plugin that recorded table names in its own rows, a serialised setting containing wp_posts, or theme code that hardcodes a table name instead of using $wpdb->prefix will still be pointing at tables that no longer exist. And the wp-config.php edit is yours to make: the tool prints the line, it cannot reach your filesystem.

How to use it

  1. Paste the output of SHOW TABLES. Borders, pipes, backticks and the row-count line are all tolerated. Leave the box empty and the twelve core tables are assumed under the current prefix.
  2. Confirm the current prefix. Usually wp_, and it has to match wp-config.php exactly. It must start with a letter and use only letters, digits and underscores, or the job is refused.
  3. Set the new prefix, or let one be generated. Leave it blank for wp plus four random lowercase letters or digits. A trailing underscore is added if you omit it, and a value identical to the current prefix is rejected.
  4. Add the database name if you need it. Optional. Filling it qualifies every table name as `db`.`table`, which matters when the SQL will be run from a connection pointed at a different database.
  5. Choose which rewrites to include. The option-name and user-meta rewrites are on by default and should stay on. The wp-config.php reminder line can be switched off if you keep your own notes.
  6. Copy the SQL, then run it yourself. Dump the database first, switch the site to maintenance mode, execute the script, run the two check queries, and change $table_prefix before you let traffic back in.

Processing & privacy

Runs on your device. Your file is processed directly in this browser.

Common use cases

Moving off the default wp_ prefix

A build handed over with the stock wp_ prefix is the most predictable database on the internet. This produces the whole change as one reviewable script rather than a dozen hand-typed renames.

A database shared with something else

Paste the full table list and only the prefixed tables are renamed. Everything else is echoed back as a comment, so you can confirm nothing unrelated was swept up.

A site with plugin tables

WooCommerce, form and log tables all begin with the same prefix and all need to move together. Feeding in the real table list catches them; assuming the core twelve does not.

Multisite installs

Per-site options tables such as wp_2_options are given their own UPDATE, and per-site capability keys are covered by the same user meta pattern.

Reviewing a change before committing to it

Because nothing is executed, the script doubles as an audit: it shows exactly how many tables move, what is skipped, and which rows would be rewritten.

Questions

Does this connect to my database?
No. It generates text in this browser tab from the table names you paste and the settings you choose. No credentials are asked for, nothing is transmitted, and the page keeps working with the network disconnected.
Does changing the table prefix actually improve security?
It is obscurity, not a fix. Automated attacks that fire a blind SQL injection payload at wp_users fail against an unknown prefix, which removes some background noise. The underlying vulnerability is untouched, and anyone with a foothold can read the prefix from wp-config.php in seconds. Treat it as one small measure alongside updates, strong credentials and rotated salts.
What happens to tables that do not start with my prefix?
They are left alone and listed as comments at the end of the script, with a count. The job is refused outright if none of the tables you pasted begin with the current prefix, since that usually means the prefix is wrong rather than the list.
Could the UPDATE statements rename something they should not?
Yes, and it is worth checking. They match every option name and meta key beginning with the old prefix, so a core option like wp_page_for_privacy_policy — which starts with wp_ but has nothing to do with the table prefix — is rewritten along with wp_user_roles. Read that section before running it, and reset the affected settings afterwards.
Do I still have to edit wp-config.php myself?
Yes. The correct $table_prefix line is printed as a comment in the script, but the file is on your server and this runs in a browser tab. Make the edit inside the same maintenance window as the renames — a config pointing at tables that have moved is a white screen.
What if I leave the table list empty?
The twelve WordPress core tables are assumed under the current prefix. That is enough for an untouched install and not enough for anything else, because plugin tables share the prefix and will be stranded. Paste the real SHOW TABLES output whenever you can.
How do I undo it?
Restore the dump you took beforehand. Failing that, run the tool again with the prefixes swapped to generate the reverse script — but the option and meta rewrites are not perfectly reversible where names were caught by the pattern, so the dump is the reliable route.
Why does the LIKE pattern have a backslash in it?
Because an underscore is a single-character wildcard in SQL. Escaping it as wp\_% means the pattern matches the literal prefix rather than wpx, wp1 or anything else with a character in that position.

Related tools