← all tools

WordPress salts generator

8 lines · 64 chars each · crypto.getRandomValues · no network request

Paste over the matching block in wp-config.php. Replacing these values invalidates every session — everyone gets logged out, including you.

What each key protects

WordPress uses eight values in pairs — a key and a salt for each of four purposes — to sign and verify authentication cookies and form tokens. Rotating all eight is safe; rotating only some leaves the others unchanged.

AUTH_KEY / AUTH_SALTSigns the main authentication cookie used to recognize a logged-in browser.
SECURE_AUTH_KEY / SALTSigns the equivalent cookie when the site is served over HTTPS.
LOGGED_IN_KEY / SALTSigns the cookie WordPress checks on every page, including the public site, not only wp-admin.
NONCE_KEY / SALTAdds entropy to the one-time tokens (nonces) that protect forms and AJAX requests from forgery.

Why generate these locally

WordPress.org's own secret-key API is the canonical source and is perfectly safe to use. This generator exists for the times that call for not making the request at all: air-gapped or restricted environments, a strict internal policy against fetching secrets from a third party at build time, or simply not wanting one more outbound HTTP call in a deploy pipeline. The randomness source is the same either way — crypto.getRandomValues, the browser's cryptographically secure generator — and nothing you generate here is transmitted anywhere.

Quick answers

Does rotating salts change anyone's password?

No. Salts and keys sign session cookies and nonces, not passwords. Replacing them logs every signed-in user out and forces a fresh login, but every password stays exactly what it was.

How often should I rotate WordPress salts?

There's no fixed schedule WordPress enforces. A reasonable baseline is a periodic rotation (many sites use roughly every 90 days) plus an immediate rotation after any suspected compromise, admin offboarding, or hosting migration. Details in the salts and secret keys guide.

Can I reuse the same salts on staging and production?

Generate a separate set for each environment. Sharing them means a cookie minted on staging is valid on production, so anyone with access to the weaker environment — often a wider group, on a site with no real protection — holds a working session key for the live one. It also makes a staging leak a production incident. Where the lines go in the file is covered on the salt generator home page.

Will rotating salts break REST API or application password clients?

No. Application passwords authenticate each request on its own rather than carrying a session cookie, so integrations keep working through a rotation that signs every human out. The same is true of anything authenticating with an application password against the REST API.