WordPress salt: 8 simple keys for a safe install

Reference

Parameters

Name	Type	Required	Description
`seed`	string	no	Makes output repeatable. Without it every request is random.
`format`	string	no	html (), php, text, json. Default: html.

Example request

curl -s "https://api2.globus.studio/v2/salt?format=json"

Open documentation

The WordPress salt generator produces the eight keys and salts that WordPress keeps in wp-config.php. A WordPress salt value signs authentication cookies and nonces. A weak or reused value makes a stolen cookie easier to forge, so every site should have its own set.

What the WordPress salt generator produces

The default output is the block of eight define() lines ready to paste into the file. The keys are AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY and the matching salts. WordPress uses them in different contexts, so every value should be different.

define('AUTH_KEY', '...');
define('SECURE_AUTH_KEY', '...');
... 8 lines total

Output formats

The format parameter accepts html, php, text and json. A json response returns the PHP block and the key names, which fits a deploy script. The html default is for a copy and paste into the file.

Random output and seeds

Without a seed every request returns a new set. The generator uses random_int, which is cryptographically secure, and the legacy alphabet excludes single quotes so the values fit the PHP file. The seed parameter makes the output repeatable for tests. Never use a public seed in production.

When to rotate the WordPress salt

A WordPress salt rotation follows a suspected compromise, after a host migration or when a developer with access leaves. Rotation logs every user out, including you. Plan it for a quiet moment, keep a backup of the old file and tell the team that sessions will reset.

Do not reuse values across environments

Production, staging and local each need a separate set. A shared set can make a staging cookie valid on production when the domain and paths overlap. Generate a new set when you clone a site, and never copy the production file to a laptop.

Putting it in the file

Open wp-config.php, find the block of eight lines and replace it with the response. Keep the file outside version control. If the deploy process writes the file, pass the values through a secret store. The WordPress salt generator does not edit the file or check the current values.

A rotation checklist

Take a backup of wp-config.php. Generate a new set. Replace the eight lines. Open the login page in a private window and sign in with an administrator account. Load a normal page and submit a form with a nonce. If something fails, restore the backup before you change anything else.

After the rotation, tell the team that sessions were reset. Review the admin passwords and remove accounts that no longer need access. Keep a private note with the date and the reason so the next person knows which values are current. The WordPress salt generator gives you the values; the checklist keeps the site online while you apply them.

Limits

The WordPress salt endpoint is fast and rate limited. It returns values for one environment at a time, so a run for staging should not feed production. If a deploy pipeline calls the API, store the response in the secret store and keep the API call out of the request path.

A local copy of wp-config.php with production values is a leak waiting to happen. Use a local database and local salts. When a developer needs to reproduce a login problem, reproduce it with a test account, not with a copy of the production file.

The generator does not check whether the site already uses the same values, and it cannot tell whether a file was edited by hand. The checklist does that part. The WordPress salt guide covers rotation and the checklist after the change.

After a rotation, review the admin passwords with the strong password generator. If the site accepts logins from anywhere, read IP bot detection before you add a block rule.

Further reading: WordPress security keys.