How the WordPress Salt Generator Works

Generate keys with the Salt Generator or the wp-config landing. Both tools are identical — they both fetch from the same live WordPress.org endpoint and present the result in a single-click copy block.

Incident walkthrough: Rotate salts after a hack. Cluster hub: WordPress.org Ops.

What wp-config salts actually are

wp-config.php contains eight security constants:

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');

WordPress uses these constants as cryptographic ingredients when creating and verifying authentication cookies and nonces. The exact value does not matter — only that it is long, random, and secret. When the constants change, all previously issued cookies become invalid because the HMAC computation produces a different result. Every logged-in session — yours, your editors’, and any attacker’s — is immediately invalidated.

What the tool does

1. You click Generate salts.
2. The proxy sends a live request to https://api.wordpress.org/secret-key/1.1/salt/.
3. WordPress.org returns eight define(...) lines with random values, each typically 64+ characters of mixed case, numbers, and punctuation.
4. The tool displays the block formatted and ready to paste.
5. Click Copy to put the full block on your clipboard.

Salts are never cached. The request is made fresh every time you click Generate. If Tools.town were to cache salts, every user who visited the page during the cache window would receive the same set — defeating the purpose entirely. This is the one endpoint in the WordPress.org Ops cluster where caching is a product bug, not a feature.

What happens when you paste new salts

The moment you save wp-config.php with new constants:

• WordPress re-reads wp-config.php on the next request.
• Every cookie WordPress issued before the change is validated against the old constants and fails.
• Every active session — including your own — is silently invalidated.
• Users are redirected to wp-login.php and must sign in again.

This is the intended behaviour. After a suspected session hijacking or cookie theft, forcing re-authentication terminates the attacker’s access to the admin session. They cannot use a stolen cookie because the cookie’s HMAC no longer matches.

Important: rotating salts does not remove malware, fix injected files, close backdoors, or scan for compromised credentials. It is one step in an incident response procedure, not a cleanup in itself.

Pasting salts into wp-config.php

The generated block looks like:

define('AUTH_KEY',         'Sz+}q^@...)Dv5...');
define('SECURE_AUTH_KEY',  'i%q7...Mx-|...');
// ... six more lines

In wp-config.php, find the existing eight define lines (they usually appear together near the top of the database section) and replace the entire block — not just a few lines. Replacing partial sets is a common mistake; it means some cookies continue to validate against old values.

After saving: visit your site in a new private/incognito window to confirm it loads before you close your current editor session. If the site throws a PHP error, you may have a syntax issue in wp-config.php (usually a stray character in the pasted value). Re-open the file and check the lines manually.

After you paste: file permissions

wp-config.php should be readable only by the PHP process user, not by other accounts on the server. The target permission mode is 600 (owner read/write only) or 640 if your setup requires the web server group to read it.

chmod 600 /path/to/wp-config.php

Verify what 600 means with the Chmod Calculator before applying. The full file permissions checklist lives at Fix WordPress file permissions.

The eight constants and what they protect

The keys and salts come in pairs. WordPress concatenates each key with its paired salt before hashing. Both must change to fully invalidate existing cookies — which is why WordPress.org’s endpoint returns all eight at once and why you should paste the full block.

When to rotate

• After a suspected account compromise — if any admin or editor credential was exposed, rotation forces sign-out across all sessions.
• After a server migration — new environment, fresh secrets.
• After a botched plugin or theme install from an untrusted source — if the plugin had access to wp-config.php, assume the old salts are exposed.
• Periodically as a hygiene measure — every 6–12 months is a reasonable cadence for sites with no incident history.
• During initial setup — if you installed WordPress and used the default placeholder values, replace them before the site goes live.

Related

• wp-config Salts Generator — same tool, different landing page
• Rotate wp-config salts after a hack
• Fix WordPress file permissions
• Chmod Calculator
• All WordPress.org Ops tools