WordPress Salt & Security Key Generator

Generate the eight WordPress authentication keys and salts in your browser, as define() lines, an array, or environment variables.

Enable JavaScript to customise; default output below.

Format

define() lines go straight into wp-config.php. The env format suits a deployment that injects configuration.

Key length

WordPress.org issues 64 characters. Longer is harmless; these are never transmitted.

Live preview salts.php
/**
 * Authentication unique keys and salts.
 *
 * Changing these logs every user out. They are not stored anywhere else,
 * so there is nothing to keep in step: rotate them whenever you want to.
 */
define( 'AUTH_KEY', 'put your unique phrase here' );
define( 'SECURE_AUTH_KEY', 'put your unique phrase here' );
define( 'LOGGED_IN_KEY', 'put your unique phrase here' );
define( 'NONCE_KEY', 'put your unique phrase here' );
define( 'AUTH_SALT', 'put your unique phrase here' );
define( 'SECURE_AUTH_SALT', 'put your unique phrase here' );
define( 'LOGGED_IN_SALT', 'put your unique phrase here' );
define( 'NONCE_SALT', 'put your unique phrase here' );

Output is valid and updates as you type.

Generate the eight WordPress authentication keys and salts. They are produced by your own browser’s cryptographic random generator and never sent anywhere, which is the one property that matters for a secret.

How to use

  1. Pick the format. define() lines go straight into wp-config.php, above the line that says to stop editing.
  2. Replace all eight existing lines. WordPress uses each of them for a different cookie, and a half-replaced set logs some users out and not others.
  3. Save the file and reload the site. Everyone, including you, is logged out. That is the expected result, not a mistake.
  4. Rotate them whenever you suspect a session was stolen, when a contractor’s access ends, or after any breach.
  5. Never commit them to a public repository. If you have, generate a new set now.

Example

define( 'AUTH_KEY',         'q!X2...' );
define( 'SECURE_AUTH_KEY',  'B7#z...' );
define( 'LOGGED_IN_KEY',    'Lp$4...' );
define( 'NONCE_KEY',        'v8@W...' );
define( 'AUTH_SALT',        'M1^c...' );
define( 'SECURE_AUTH_SALT', 'r6&K...' );
define( 'LOGGED_IN_SALT',   'T3*n...' );
define( 'NONCE_SALT',       'Z9(j...' );

There is nothing to keep in step with these: no database record, no other file. They exist only in wp-config.php, which is why changing them is safe and immediate.

Pitfalls

  • Changing the keys logs every user out, including you. On a membership site, tell people first.
  • Replacing only some of the eight leaves old cookies partly valid, which produces intermittent logouts that are very hard to debug.
  • The four _KEY constants and the four _SALT constants are not interchangeable. Keep the names exactly as WordPress defines them.
  • A salt generator that runs on someone’s server means that server saw your keys. This one runs in your browser; check any other you use.
  • Keys left as put your unique phrase here mean every cookie on the site is signed with a value anybody can look up.
  • Committing wp-config.php to a repository publishes them. Rotating is the only fix once that has happened.
  • NONCE_SALT affects form nonces as well as cookies, so a user with a form open when you rotate gets an expired nonce.
  • Backups contain the old keys. A restore reverts them, and every session issued since is invalidated again.

Compatibility

All eight constants have been read by WordPress since 3.0 and are still current in WordPress 6.x. Any printable ASCII is valid; WordPress.org’s own service issues 64 characters. The generated values come from crypto.getRandomValues, available in every browser since 2014. Nothing is uploaded and nothing is logged.

Frequently asked questions

Will changing these log everyone out?
Yes, immediately. Existing cookies can no longer be verified, so every session ends.
How often should I rotate them?
There is no schedule. Rotate after a suspected compromise, when someone with server access leaves, or if the keys were ever committed to a repository.
Are these the same as a password?
No. They are used to sign and verify cookies and nonces. No user types them, and they are never sent to the browser.
Can I use longer keys?
Yes. WordPress does not check the length. 64 characters is already far past the point of usefulness.
Where exactly do they go?
In wp-config.php, replacing the existing block, before the line about not editing past that point.

From the people who built this tool

WP Adminify

The WordPress admin, rebuilt: a dashboard worth looking at, menu and column control, a real file manager and the login page your client sees.

See WP Adminify Free version on WordPress.org

Weekly drops

New tools, when there are new tools

One email when something worth using ships. No schedule to fill, so no filler.

Your address goes nowhere else, and one click unsubscribes.