What Table Is the Admin Info Stored in WordPress?

WordPress keeps admin account details in the wp_users table: username, password hash, email and display name. The admin role itself lives in the wp_usermeta table, in the wp_capabilities row for that user. The site-wide admin email shown under Settings, General is a separate value in the wp_options table, named admin_email.

The wp_ part is only the default table prefix. Your install may use something else, so check $table_prefix in wp-config.php before you run any query. Back up the database first, then read on for exactly which column holds what.

The short answer: where each piece of admin info lives

There is no separate “admin table”. An administrator is an ordinary user whose role is set to administrator. That splits the information across three places.

What you want	Table	Column or key
Admin username (login)	wp_users	user_login
Admin password (hashed)	wp_users	user_pass
Admin email	wp_users	user_email
Name shown on the site	wp_users	display_name
Admin role	wp_usermeta	meta_key = wp_capabilities
Site admin email (notifications)	wp_options	option_name = admin_email

The same wp_users table also holds your editors, authors, customers and members. On a community site that can mean thousands of rows, so always filter by ID or login when you query it.

What is inside wp_users

Each row is one account. These are the columns WordPress creates, as listed in the developer documentation for the database schema:

• ID: the unique user ID. The first account created during install is normally ID 1.
• user_login: the username used to log in.
• user_pass: the password hash. WordPress never stores the plain password.
• user_nicename: the URL-friendly name used in author archive links.
• user_email: the account email address.
• user_url: the website URL from the profile.
• user_registered: when the account was created.
• user_activation_key: the key used by the password reset flow.
• user_status: a legacy column that core no longer uses for anything important.
• display_name: the name shown publicly on posts and comments.

A quick read-only query to find your admin row looks like this:

SELECT ID, user_login, user_email, display_name, user_registered
FROM wp_users
WHERE user_login = 'your-username';

How the admin role is stored in wp_usermeta

The wp_usermeta table is a key and value store with four columns: umeta_id, user_id, meta_key and meta_value. Each user has many rows. Two of them describe the role:

• wp_capabilities holds a serialized array of roles. For an administrator the value is a:1:{s:13:"administrator";b:1;}.
• wp_user_level is a legacy numeric level from before roles existed. Administrators have 10. Modern code reads capabilities, not this number.

Notice that the key name starts with the table prefix. If your prefix is site7_, the key is site7_capabilities. This is the most common reason a hand-written query “finds nothing”. To list every administrator on a site, run:

SELECT u.ID, u.user_login, u.user_email
FROM wp_users AS u
INNER JOIN wp_usermeta AS m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%"administrator"%';

Run this after a suspected break-in. An administrator you do not recognise is the first thing to look for. Do not edit the serialized string by hand. The string stores character counts, so a typo corrupts the whole value and the user loses every capability.

The site admin email lives in wp_options

People often mean something different when they say “admin email”: the address that receives new user notices, update alerts and comment moderation mail. That is the admin_email option, not the user’s own address.

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('admin_email', 'new_admin_email');

The new_admin_email option appears while a change is waiting for confirmation. WordPress emails the new address and only switches admin_email once the link is clicked. You can change it from Settings, General without touching the database. If that email never arrives, see our guide on stopping email change confirmation emails in WordPress.

Multisite adds two more places. All users share one wp_users table, and the network admin email sits in wp_sitemeta under admin_email. Super admins are listed in the site_admins row of the same table. Each site also has its own options table, such as wp_2_options.

Find your real table prefix

WordPress reads the prefix from wp-config.php:

$table_prefix = 'wp_';

Some hosts and security setups change it to a random string. If you can run WP-CLI, this prints the exact prefix and every table WordPress owns:

wp db prefix
wp db tables

In PHP code, never hard-code wp_. Use $wpdb->users, $wpdb->usermeta and $wpdb->options, which always contain the right names.

How to view the data safely

You have four sensible options. Pick the one that matches your access level.

1. WP-CLI. Run wp user list --role=administrator to list admins without opening a database tool. It reads through WordPress, so prefixes and multisite are handled for you.
2. The Users screen. Users, All Users in the dashboard, filtered by Administrator, shows the same information with no risk.
3. phpMyAdmin or Adminer. Most hosts offer phpMyAdmin in the control panel. Adminer is a single PHP file you upload temporarily. Delete it when you finish, because a leftover database tool is an open door.
4. A database client over SSH tunnel. Tools such as TablePlus or MySQL Workbench connect through an encrypted tunnel, which is safer than opening the database port to the internet.

Whichever tool you use, export a backup first. Most hosts offer a one-click snapshot, and wp db export backup.sql works anywhere WP-CLI is installed. Keep the file outside the web root.

Reset an admin password the safe way

The old advice was to edit user_pass in phpMyAdmin and choose the MD5 function. That still works, because WordPress keeps a fallback that accepts a 32 character MD5 value and then rewrites it as a modern hash at the next login. But MD5 is a weak legacy format. Treat it as a last resort, and prefer one of these in order:

1. Lost password link. Use the “Lost your password?” link on the login page. It needs working email on the site.
2. WP-CLI. This sets a properly hashed password in one command:

   wp user update 1 --user_pass='a-long-unique-passphrase'

   Replace 1 with the user ID or login.

3. A one-time snippet. If you have file access but no shell, add this to the active theme’s functions.php (a child theme is best), load any page once, and remove it straight away:

   add_action( 'init', function () {
   	wp_set_password( 'a-long-unique-passphrase', 1 );
   } );

   It uses wp_set_password(), which hashes the value before saving it. If you forget to remove it, the password resets on every page load.

4. Direct database edit. Only if nothing above works. In phpMyAdmin, edit user_pass for the right ID, choose MD5 in the function dropdown, save, log in, then change the password again from your profile so it is re-hashed.

How passwords are hashed has changed. Since WordPress 6.8, new password hashes use bcrypt, stored with a prefix beginning $wp so they are distinguishable from plain bcrypt. Older sites show the classic phpass format, which starts with $P$. Both are accepted, and existing hashes are not invalidated. This is why you should never try to build a hash by hand.

Create an admin user when you are locked out

If your admin account was deleted, or you cannot reach it, WP-CLI is the cleanest repair:

wp user create rescue rescue@example.com --role=administrator --user_pass='a-long-unique-passphrase'

Without a shell, inserting rows by hand into wp_users and wp_usermeta is possible, but easy to get wrong because the capabilities value is serialized. A one-time snippet that calls wp_insert_user() is safer. Remove it as soon as you are back in, and delete the rescue account after you finish.

Troubleshooting a missing or demoted admin

Work through these checks in order:

1. Look for the account in wp_users. If the row is gone, restore from a backup or create a new admin as above.
2. If the row exists, check wp_usermeta for the wp_capabilities key using your real prefix. A missing row means the user has no role at all, which looks exactly like a demotion.
3. After a migration or a prefix change, confirm that the capabilities and user_level keys, and the user_roles option in wp_options, all use the new prefix. A mismatch locks every administrator out at once.
4. Check for unknown administrators. Compromised sites often gain a hidden admin. Compare the list from the earlier query with the people who should have access.

Why this matters more on a large community site

A blog has a handful of users. A community site, course platform or marketplace can have thousands, and every plugin adds its own user meta. Three habits keep that manageable:

• Query by indexed columns. ID and user_login are indexed in wp_users. In wp_usermeta, user_id and meta_key are indexed, meta_value is not, so a LIKE on it scans the table. Keep those queries for audits, not page loads.
• Use core functions in code. get_users(), WP_User_Query and get_user_meta() handle prefixes, caching and multisite.
• Keep the number of administrators small. Give moderators and managers a narrower role instead of full admin rights.

If you are planning a site with many members, hosting and caching matter as much as the schema. Our notes on hosting a community site and on how Reign scales cover that side.

Best practices for working in the database

• Back up before every change, and confirm the backup restores.
• Prefer the dashboard or WP-CLI over raw SQL. They respect hooks, caches and multisite.
• Use prepared statements in custom code: $wpdb->prepare() for any value that came from a user or a request.
• Do not use “admin” as a username and do not leave the ID 1 account with a guessable login. Attackers try both first.
• Enable two-factor authentication for every administrator with a maintained plugin.
• Remove temporary tools and snippets the moment you finish.

Related reading on this blog: should you upload your entire WordPress site to GitHub explains what never to commit, including wp-config.php, which holds your database credentials.

Frequently asked questions

What table is the admin username stored in?

The admin username is stored in the user_login column of the wp_users table. The password hash and email are in the same row, in user_pass and user_email.

Where does WordPress store the admin role?

The role is stored in the wp_usermeta table, under the wp_capabilities meta key for that user. An administrator has the value a:1:{s:13:"administrator";b:1;}. If you use a custom table prefix, the key starts with that prefix instead of wp_.

Where is the admin email stored in WordPress?

The site admin email is the admin_email option in wp_options. The email on an individual account is user_email in wp_users. They can be different addresses.

Are WordPress passwords stored in plain text?

No. The user_pass column holds a hash. Since WordPress 6.8 new hashes use bcrypt, and older sites may still show phpass hashes that start with $P$. Neither can be turned back into the original password.

Can I change the admin password directly in the database?

Yes, but it is a last resort. Use the lost password link, wp user update in WP-CLI or wp_set_password() first. If you edit user_pass with phpMyAdmin, back up first and change the password again after you log in.

Is the table always called wp_users?

No. The wp_ part is the table prefix set by $table_prefix in wp-config.php. Run wp db prefix to see yours, and use $wpdb->users in PHP.

How do I see all admin users on my site?

The easiest way is Users, All Users in the dashboard with the Administrator filter, or wp user list --role=administrator in WP-CLI. The SQL join on wp_usermeta shown above gives the same list.

Next step

If you run a site with a lot of members, the user tables are the part of your database that grows fastest. Reign is the WordPress theme for building a complete community site: social network, courses, member directory, marketplace and job board on one install. Open the live demos to see it with real content, or follow the community build guide for a step-by-step setup.