Four ways to change a WordPress password, in order of how often you'll reach for them: dashboard, WP-CLI, database, email reset. The dashboard is obvious; the interesting ones are WP-CLI (fast for many sites at once) and the database edit (the only option when you're locked out completely).
Set the WordPress username and new password once. The WP-CLI and SQL examples below update so you can copy and run. The SQL uses the default wp_ prefix; if yours differs, adjust the wp_users table name to match.
Method 1: From the WordPress admin
Users → Edit user → scroll to Account Management → Set New Password. WordPress 6.8+ generates a strong default; click Update Profile to save. The session you used to log in stays valid; other active sessions for that user are signed out.
Method 2: With WP-CLI
wp user update :username --user_pass=':new_password' --skip-emailadmin can be the user ID, login, or email. --skip-email suppresses the password-changed notification. WP-CLI hashes the password using whatever default your WordPress version uses (phpass on 2.5–6.7, bcrypt on 6.8+), so you don't have to think about hash format.
If WP-CLI isn't installed:
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar && sudo mv wp-cli.phar /usr/local/bin/wpMethod 3: Directly in the database (when you're locked out)
The case where this matters: no admin access, no working email delivery, no shell to run WP-CLI. Just database access via phpMyAdmin, Adminer, or mysql.
The wp_users.user_pass column accepts three formats depending on your WordPress version:
| WP version | Format | Looks like |
|---|---|---|
| 2.5 – 6.7 | phpass | $P$B... (34 chars) |
| 6.8+ (Apr 2025) | bcrypt | $wp$2y$10$... (63 chars) |
| Any version | Plain MD5 (legacy) | 32 hex chars |
Don't write your plaintext password into user_pass. WordPress only validates hashed values, so the login will silently fail. And don't compute the hash with MD5('your-password') directly in SQL just because that's what every 2014 blog post tells you to do. That technically works (WordPress accepts the MD5 and auto-rehashes on first successful login), but it's the weakest of the three options and there's no reason to use it when you can generate the modern format up front.
The cleanest move is to hash the password ahead of time. dnschkr.com's WordPress Password Hash Generator outputs all three formats from a single password input: phpass for legacy sites, $wp$2y$ bcrypt for WordPress 6.8+, and the legacy MD5 if you specifically want the auto-upgrade-on-login behavior. It runs entirely in your browser, so the plaintext password never leaves the page.
Copy whichever format matches your WordPress version and apply it in SQL:
-- Default table prefix: wp_ (adjust the table name if yours differs)
UPDATE wp_users
SET user_pass = '$wp$2y$10$HpMK.ev1QPoDbpPDO6dde.ZKvwIPBDVNKDcFDocgLHsWRg3CL9NMK'
WHERE user_login = ':username';If you customized your table prefix (the default is wp_), use that prefix on the users table name in the UPDATE statement. Log in once with the plaintext password and you're back in.
Method 4: The lost-password email flow
The underrated method. From /wp-login.php?action=lostpassword, enter the username or email, click submit, and WordPress emails a reset link. This only fails if (a) email delivery is broken or (b) you don't have access to the user's inbox.
If you have shell but not admin, WP-CLI can force a reset and print the new password to your terminal:
wp user reset-password :username --skip-emailWhatever method you pick, pick a long password. A 16-character random string under bcrypt is uncrackable for any realistic adversary; a six-character one under bcrypt cracks in minutes. If you don't already have one in your password manager, dnschkr.com's WordPress Password Hash Generator is the cleanest way to go from a fresh password to the exact format your WordPress version stores.
WordPress 6.8+ (released April 2025) stores new passwords as bcrypt with a $wp$2y$10$ prefix (63 characters total).
WordPress 2.5 – 6.7 uses phpass with a $P$B prefix (34 characters).
Both formats coexist in older databases. WordPress upgrades each row to the current default the next time that user logs in successfully, so a phpass row gets rewritten as bcrypt on the next correct login after you upgrade to 6.8.
Yes. wp_check_password() detects a 32-hex-character value with no $ prefix as legacy MD5, re-hashes the typed password as MD5, and on match calls wp_set_password() to rewrite the row in the current default format.
This back-compat path dates from the 2008 phpass migration and still works in 6.8+. It's the weakest option of the three but the most universally compatible if you're not sure what version you're on.
WP-CLI uses the same DB_HOST and credentials as WordPress itself. The most common cause is a stale MySQL socket path in wp-config.php. If WordPress itself is also failing to reach the database, that is the broader "Error Establishing a Database Connection" problem rather than a WP-CLI quirk.
Two things to try:
- Set
DB_HOSTto127.0.0.1:3306instead oflocalhostto force a TCP connection. - Pass
--skip-themes --skip-pluginsto rule out a plugin hooking into bootstrap and crashing before WP-CLI gets to the database.
Yes. Passwords are stored in the network-level wp_users table, not per-site. wp user update works identically.
For the database method, edit the single network wp_users row and the change applies across every subsite that user belongs to.
Editing user_pass only is safe. WordPress doesn't cache password hashes anywhere else.
Don't touch the user_login or ID columns of an existing row. Foreign keys in wp_usermeta, wp_posts, and wp_comments reference the user ID and will point at the wrong user if you change it.
Back up the row before editing if you're nervous:
SELECT * FROM wp_users WHERE user_login = 'admin';
See also
- Validate Password Strength with Regex: the pattern to enforce length and character-class rules on the new password before it goes into
wp_users - How to Reset a Forgotten MySQL Root Password: the parallel reset flow at the database layer, including the
--init-filemethod and the MySQL 8.4 auth-plugin changes - Meeting Matt Mullenweg at WordCamp Europe 2024: the WordPress maintainer behind the platform you just touched, in conversation about where the project goes next
- WordPress AMP Plugin: Enable Custom Post Types: plugin configuration on the same WordPress install, useful right after a password reset when you are auditing what is enabled
- How to Remove WordPress Malware: The Practitioner's Playbook: the broader cleanup methodology; password rotation is step 7 of the flow and assumes the site was compromised
- fix "briefly unavailable for scheduled maintenance": delete the leftover .maintenance file.
- the database-connection error stuck in cache: when the DB recovered but a cached page keeps serving the error, the cache-clear steps that actually fix it.
- disable WordPress emojis: drop the emoji script for a quick speed win.
Sources
Authoritative references this article was fact-checked against.
- WordPress Core developmentmake.wordpress.org
