WordPress Password Generator

Generate a strong password and the exact hash WordPress stores in wp_users.user_pass — phpass $P$B for any version, or $wp$2y$ bcrypt for 6.8+ — with ready WP-CLI, phpMyAdmin and SQL snippets.

100% Free

The password is drawn here; the hash is made on our server

Neither of WordPress's two formats can be computed in a browser, so the value is sent over HTTPS for PHP to hash. It is never written to a log, a database or a file, and it is gone the moment the response is sent. Use this for a new password you are about to set — not for one you already use elsewhere.

WordPress Password Generator

Sixteen random characters is comfortably past anything brute force reaches. WordPress imposes no upper limit worth worrying about.

Lowercase

a–z

Uppercase

A–Z

Digits

0–9

Symbols

Safe to paste anywhere

Avoid look-alike characters

Leaves out I, l, 1, O, 0 and o, which get misread when a password is typed from a screen.

Any format WordPress accepts, including the plain MD5 rows a site untouched since 2008 still has.

Hash format

Works on every WordPress ever released, 6.8 included. Choose this if you are not certain of the version.

WordPress 6.8 and newer only. Much stronger, but older versions cannot read it and the login will simply fail.

WordPress passes no cost at all, so it gets PHP's default. Raising it here is allowed, but WordPress will treat the hash as due a rehash at the next login.

Result

100% Free

All tools are completely free to use.

Privacy First

Your files are never uploaded or stored on our servers.

Super Fast

Compress and process files in seconds.

High Quality

Best results with minimal quality loss.

What is WordPress Password Generator?

WordPress Password Generator does the two things you need together when you are locked out of a site: it draws a strong random password, and it turns that password into the exact string WordPress expects to find in the user_pass column of wp_users.

Two formats, and picking the wrong one locks you out

WordPress changed how it hashes passwords in version 6.8, released in April 2025, and both formats are still in use.

The older one is phpass, the portable hash that starts $P$B and is exactly 34 characters long. It is an MD5 chain run 8,192 times over the password and an 8-character salt. Every WordPress from 2.5 onwards accepts it, including 6.8 and later — which makes it the safe choice when you do not know what version the site is running.

The newer one is bcrypt, stored as 63 characters beginning $wp$2y$. That $wp in front is not decoration: it is how core tells its own hashes from anyone else's, and wp_check_password() strips it before calling password_verify(). It is far stronger than phpass, but WordPress 6.7 and earlier cannot read it, and a login attempt against one just fails with no useful message.

Why WordPress bcrypt has no 72-byte limit

Bcrypt everywhere else silently ignores everything past the first 72 bytes of a password, which is how two different long passphrases can open the same account. WordPress avoids it: before bcrypt sees anything, the password is run through an HMAC-SHA-384 under the fixed key wp-sha384 and base64-encoded. That is always 64 characters, whatever went in — so a 300-character passphrase is fully accounted for, and this tool will not quietly truncate it the way a general-purpose bcrypt generator does.

Getting it into the database

Once you have a hash, the output gives you the snippets to place it: the WP-CLI commands to reset a user or create an administrator, an UPDATE for phpMyAdmin when the site will not boot, a full INSERT that builds an admin account from nothing including the two usermeta rows that actually grant the role, and a throwaway mu-plugin for when FTP is all you have. The table prefix from your wp-config.php is applied throughout — including to the wp_capabilities and wp_user_level meta keys, which carry it too and are the usual reason a hand-written recovery query runs cleanly and changes nothing.

What happens on our side

The password is drawn in your browser with crypto.getRandomValues(), the same generator a password manager uses, from a pool that leaves out quotes, backslashes, dollar signs and backticks — because this password has to survive a shell command, an SQL statement and a PHP string on its way in.

The hashing is the one part that cannot happen in your browser, so that value is sent over HTTPS, hashed, checked once against the same logic wp_check_password() uses, and discarded. Nothing is logged or stored. Use this for a password you are about to set, not one you already rely on.

How to Use WordPress Password Generator

  1. 1

    Pick the hash format

    phpass works on every WordPress version; bcrypt is stronger but needs 6.8 or newer. Choose phpass if you are unsure which the site runs.

  2. 2

    Press Generate password

    The password is drawn in your browser and sent to be hashed into a real WordPress user_pass value.

  3. 3

    Copy the password first

    It cannot be recovered from the hash. Save it in your password manager before you leave the page.

  4. 4

    Set your username and table prefix

    The prefix is $table_prefix from wp-config.php. It changes the table names and the two capability meta keys in the snippets.

  5. 5

    Run the snippet that fits

    WP-CLI if you have shell access, the UPDATE statement in phpMyAdmin if the site will not boot, or the mu-plugin if all you have is FTP.

  6. 6

    Check it if you want to

    Switch to Verify, paste a user_pass value straight from wp_users, and see whether WordPress would accept that password.

Frequently Asked Questions

If you know the site is on WordPress 6.8 or newer, choose bcrypt; it is significantly stronger. If you are not sure, choose phpass. Every WordPress release since 2.5 accepts a $P$B hash, 6.8 and later included, so it always works — and on 6.8+ core quietly upgrades it to bcrypt the next time that user logs in. A bcrypt hash on an older site simply fails to verify, and the login page will only tell you the password is wrong.
Generate the password, copy the UPDATE statement, and change the username in it to match your account. Run it against your site database. The statement also clears user_activation_key, which matters — wp_set_password() clears it too, and leaving an old password-reset link valid undoes the point of the reset. If you would rather edit the row by hand, paste the hash on its own into the user_pass field.
So core can recognise its own. wp_check_password() looks at the prefix to decide which branch to take: $wp means strip those three characters, re-derive the HMAC-SHA-384 pre-hash and call password_verify(); $P$ means run it through phpass instead. A plain bcrypt hash with no prefix falls through to a compatibility branch and does still verify, but core never writes one, so a bare $2y$ string in user_pass means something other than WordPress put it there.
On 6.8+ it will work, because of that compatibility branch — but WordPress will treat it as needing a rehash and replace it at the next login. On 6.7 and earlier it will not work at all. It is also missing the SHA-384 pre-hash, so it carries bcrypt's 72-byte truncation, which WordPress's own hashes do not.
Both formats generate a fresh random salt for each hash and store it inside the output — the 8 characters after $P$B for phpass, the 22 after the cost for bcrypt. That is what stops two users with the same password having the same row, and what makes precomputed rainbow tables useless. There is no separate salt column in wp_users; the whole string goes in one field.
A plain, unsalted MD5, which is what WordPress 2.4 and earlier stored. Core still accepts these on login so that nobody is locked out of a very old site, and replaces the row with a modern hash the moment that user signs in. It is not a password hash in any meaningful sense — if you have found one, reset it rather than leaving it.
Because WordPress does. wp_hash_password() calls trim() before it hashes, on both the phpass and the bcrypt path, so leading and trailing whitespace is never part of a WordPress password. Worth knowing: wp_check_password() does not trim, so a password stored with spaces at the edges can never be typed back in. The tool shows you the trimmed form, which is the one that actually works.
Yes, whenever you have shell access. "wp user update admin --user_pass=..." lets the site's own WordPress do the hashing, so you get the right format for that version without having to choose. Pasting a hash by hand is for the case WP-CLI cannot help with — the site that will not boot, or the host that gives you phpMyAdmin and nothing else.

Stay Updated

Get the latest tools, AI features, and product updates. No spam.