Salt Key Generator

Produce a new set of WordPress authentication keys and salts, in the format your install actually reads.

Runs on your deviceWordPressWorkingNo account needed

What this tool does

Salt Key Generator produces the eight constants WordPress uses to sign its cookies and nonces: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY and NONCE_KEY, with the matching AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT and NONCE_SALT. Every character is drawn from crypto.getRandomValues through rejection sampling, so the spread is even rather than tilted towards the start of the alphabet the way a plain modulo would tilt it.

The default character set is the one api.wordpress.org draws from, and it deliberately leaves out the apostrophe and the backslash so each value sits inside a PHP single-quoted string without escaping. It does still contain $, braces, backticks and a space, which certain .env readers and container tools treat as syntax rather than text — that is what the letters-and-digits-only option is there for. The same eight constants can be emitted as wp-config.php defines, WP-CLI wp config set commands, .env assignments or a JSON object, though the format is picked before the run and every run mints new values — there is no way to re-emit one set in a second format.

Two limits are worth knowing before you paste anything in. This tool writes nothing: it hands you text, and you edit your own file — assembling a complete configuration is what wp-config Generator does instead. And when you paste an existing block, only define() lines are scanned, for constant names ending in KEY or SALT, so extras are carried over and regenerated from a PHP block but not from a .env or JSON one. It never reads your current values or checks whether they are still the placeholder phrase; everything it names comes back with a fresh value regardless.

Replacing these constants ends every logged-in session on the site, including your own, because the cookies were signed with the old keys and no longer verify. Nonces stop matching as well, so a form somebody left open fails until the page is reloaded. Stored passwords are untouched — they are hashed separately from any of this — so nobody has to reset one; they simply sign in again.

How to use it

  1. Paste an existing block, or start from empty. The input is optional. Paste the salt section of wp-config.php only when you have extra KEY or SALT constants you want carried over and regenerated alongside the standard eight.
  2. Pick the format your setup reads. wp-config.php defines, WP-CLI wp config set commands, .env assignments for Bedrock-style installs, or a JSON object for configuration management.
  3. Set the length and the characters. Anything from 32 to 128 characters, clamped to that range; 64 is what the official service issues. Switch to letters and digits when something between the clipboard and PHP mangles punctuation.
  4. Run, copy, then replace the old lines in one edit. Copy output takes the whole set at once. Swapping only some of the constants leaves part of the cookie set still valid and part of it broken, which is a confusing state to debug.

Processing & privacy

Runs on your device. Your file is processed directly in this browser.

Common use cases

Taking over a site from someone else

Anyone still holding the old wp-config.php, together with a copy of the database it belonged to, holds what is needed to mint a valid login cookie. New constants retire that pair.

Ending every session after a compromise

One edit invalidates the login cookies of every account at once, so a stolen session dies without visiting each user in turn or forcing password resets.

Cloning production to staging

The copy inherits production's signing material until you change it. Generating a separate set keeps the two installs from validating each other's cookies.

Several sites sharing one Redis or Memcached

Tick WP_CACHE_KEY_SALT and each install gets its own cache namespace, so an object-cache drop-in cannot hand one site's entries to another.

Questions

Do the generated keys reach a server at any point?
No. The values are produced in this browser tab by crypto.getRandomValues and are never transmitted or stored, so they exist only in your clipboard and your config file. A tab that is already open keeps minting sets after the connection drops, although the site installs no offline copy of itself, so fetching the page in the first place still needs the network.
Do I have to use the official WordPress salt service instead?
No, and there is no functional difference in the result. This draws from the same character set api.wordpress.org uses, adds the WP-CLI, .env and JSON formats, and needs no request to a third party to produce a set.
Will everyone be logged out?
Yes, and that includes you. Login cookies are signed with the auth keys and salts, so they stop verifying the moment the constants change. Sign in again with the same password — passwords are not affected by this.
How long should each value be?
64 characters unless you have a specific reason otherwise. That is what the official service issues, and it already carries far more entropy than the hashing consumes. The field accepts 32 to 128 and clamps anything outside that.
Why would I choose letters and digits only?
Because the full set includes $, spaces, backticks and braces. PHP handles them fine inside single quotes, but some .env readers, YAML files and container tools expand or mangle them. If a value copies cleanly yet breaks on load, that is usually the cause.
Can it edit wp-config.php for me?
No. It returns text for you to paste in yourself. If you want the whole file built — database credentials, table prefix, debugging constants and a salt block together — use wp-config Generator.
What happens to extra constants I have defined?
A pasted block is scanned for define() lines whose name ends in KEY or SALT, and anything beyond the standard eight is appended and regenerated with the rest. Names written in .env or JSON form are not detected, so paste the PHP version when you have extras.

Related tools