Where is the WordPress users table?

Start with the configured table prefix

The most reliable answer is in the site’s wp-config.php. Look for the line that sets $table_prefix. If it is wp_, the expected users table is wp_users. If it is client_, it becomes client_users.

Do not assume the database is named after the domain, and do not use a table merely because it contains the word “users.” Hosting accounts often contain staging, old, and unrelated WordPress installations in the same database server.

A prefix mismatch after a migration is one of the most common causes of a broken-looking site — see login failures after a migration if that's what brought you here.

Find it with one query instead

Reading $table_prefix is the reliable answer, but it assumes you can open wp-config.php. From a database client you can ask the database directly — and on a hosting account holding several old installs, that is often the faster route to the truth.

-- Inside the database you believe the site uses.
SHOW TABLES LIKE '%users';

One result is the easy case. Several means this database holds more than one WordPress install, and the prefix is the only thing that tells them apart — which is exactly the situation where picking the wrong one produces a recovery that appears to work and changes nothing.

-- When you do not know which database, let alone which prefix.
-- Lists every users-style table the connection can see, and where it lives.
SELECT table_schema AS db, table_name, table_rows
FROM information_schema.tables
WHERE table_name LIKE '%users'
ORDER BY table_schema, table_name;

information_schema is a virtual database every MySQL and MariaDB server exposes, listing the structure of everything the connected user has rights to. A shared-hosting account usually sees only its own databases, which is what makes this practical rather than alarming. The table_rows estimate is a useful tiebreaker: a staging copy abandoned two years ago rarely has the same user count as the live site.

Confirm with a row before you trust the name — the table you want has user_login, user_email and user_pass columns. Anything called users without a prefix, or without those columns, belongs to some other application sharing the server.

Recognize the table you need

What is actually in these two tables

The columns in wp_users

Ten columns, and only one of them is a credential. Knowing the rest is what stops a recovery turning into an accidental account edit.

Multisite adds two more — spam and deleted — which the network uses to suspend an account without removing its content.

Roles live in wp_usermeta, under a prefixed key

There is no role column in wp_users. A user's role is a row in the meta table whose meta_key is the site's table prefix followed by capabilities — wp_capabilities by default, client_capabilities on a site with a custom prefix — holding a serialized PHP array.

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

The stored value looks like a:1:{s:13:"administrator";b:1;}. That string length — s:13 — has to match the word that follows it, which is why hand-editing serialized data breaks roles so reliably, and why the prefix in the meta key is the thing everyone forgets when changing a table prefix: rename the tables without renaming this key and every user silently loses their role.

Find it in phpMyAdmin, step by step

1. 01
   Open the database named in wp-config.php.

   Match DB_NAME to the database selector before browsing any tables.

2. 02
   Find the prefix, then locate _users.

   Use the configured prefix as the first filter. A table ending in _users should have fields such as ID, user_login, user_email, and user_pass.

3. 03
   Confirm the exact authorized account.

   Search by user_login or user_email, never by a row number or a display name that might be duplicated.

4. 04
   Leave unrelated tables alone.

   Do not edit usermeta, roles, or site content merely to recover a password. Make the smallest necessary change.

Use WP-CLI when you have shell access

WP-CLI can read the active configuration, which removes much of the naming guesswork. These commands are read-only and help confirm the prefix and tables WordPress recognizes.

WP-CLI can also reset a password directly once you've confirmed the account — see the WP-CLI password reset guide.

On multisite, users are the exception

The confusion about numbered tables comes from a real asymmetry: content is per-site, identity is not. Site 2's posts live in wp_2_posts, but site 2's users are rows in the same wp_users everyone else uses. There is no wp_2_users on a standard network.

Two consequences follow. A password reset applies network-wide, because there is only one hash to change. And an account that can sign in but sees “You do not have sufficient permissions” on one site has its identity intact and its capabilities row missing for that site — a different problem from a password one, and not fixed by resetting the password again.