Database navigation guide

Where is the WordPress users table?

Find the correct wp_users-style table before you inspect or recover an authorized account. The name depends on the site’s table prefix and, in multisite, the site ID.

5 min readUpdated 26 July 2026phpMyAdmin and WP-CLI
01wp_users is only the default.

A custom installation prefix changes the table name, for example to client_users.

02usermeta is a companion table.

Roles and capabilities usually live in the matching _usermeta table, not in _users.

03Multisite adds site-specific tables.

Network users are shared, while sites can use numbered table prefixes for their own content.

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.

1 Read $table_prefix2 Add users3 Open matching table

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.

Recognize the table you need

What you seeLikely meaningNext check
wp_usersDefault single-site users tableConfirm that $table_prefix is wp_.
client_usersCustom-prefix users tableCheck for $table_prefix = 'client_';.
wp_usermetaMetadata for the matching users tableUse it to inspect roles only after identifying the right user.
wp_2_postsA multisite site tableThe number identifies a site; do not infer the shared users table from posts alone.

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.

Show the configured prefix wp db prefix
List tables using that prefix wp db tables --all-tables-with-prefix

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

Before you edit a user record

  1. Confirm you are administering the correct site and have a recoverable backup.
  2. Match DB_NAME and $table_prefix to the table you opened.
  3. Identify the authorized user by login or email, then change only the required field.
  4. Prefer the normal reset route or WP-CLI before a direct database edit.

Quick answers

Is it safe to rename the table prefix?

It's possible but not routine — every plugin, theme, and serialized option that references the prefix has to be updated consistently, and a partial rename breaks the site. Most sites never need to; see changing the table prefix safely if you have a real reason to.

What's stored in the usermeta table if not the password?

Roles and capabilities, the user's display name preferences, admin color scheme, dismissed notices, and plugin-specific per-user settings — all as flexible key/value rows tied to a user ID, rather than fixed columns like user_pass.

Why do I see numbered tables like wp_2_users on multisite?

Only on some multisite setups: the shared wp_users table covers accounts across the whole network, but a few tables (not users) are per-site with a numeric infix. A user's identity lives in the shared table regardless of which site they're active on.

Primary references: WordPress database table-prefix reference and WP-CLI: wp db tables.