A WordPress salt generator produces the eight keys and salts that WordPress keeps in wp-config.php. A WordPress salt generator creates values that sign cookies and password hashes. A weak or reused value makes a stolen cookie easier to forge. The values should be long, random and unique to the site.
The WordPress salt endpoint returns the eight constants ready to paste into the file.
curl "https://api2.globus.studio/v2/salt?format=php"What a WordPress salt generator produces
A WordPress salt generator creates a value for each context. AUTH_KEY, SECURE_AUTH_KEY and LOGGED_IN_KEY sign authentication cookies. NONCE_KEY signs nonces. The four salt constants do the same job in different contexts. WordPress uses them together, so every value should be different.
When to rotate
Rotate the salts after 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 and keep a backup of the old file.
Do not rotate on a schedule just because a tutorial says so. Every rotation ends active sessions and can break integrations that cache a cookie.
Repeatable output for tests
The WordPress salt generator accepts a seed parameter. The same seed returns the same set, which is useful in a test fixture. Without a seed, every request returns a new set. Never use a seed in production.
curl "https://api2.globus.studio/v2/salt?seed=test&format=json"Putting it in the file
To apply a WordPress salt, open wp-config.php, find the block of eight define() lines and replace it with the response. Keep the file outside version control. If your deploy process writes the file, pass the values through a secret store, not through a repository.
Do not reuse values
Each site needs its own set. A staging copy with production salts can share cookies with the live site if the domain and paths overlap. Generate a new set for every environment.
Limits
A WordPress salt generator produces values; it does not edit your file or check the current ones. The response is plain PHP code or JSON. Read the endpoint documentation for parameters and examples.
What breaks after rotation
Every active login ends. Password reset links that use a nonce can stop working. A cached cookie in an integration fails. The site itself keeps working, but users have to sign in again.
Plan the change for a low-traffic window. Tell the team. Keep the old wp-config.php until the new one is confirmed. If the site uses a deploy pipeline, rotate the values in the secret store and redeploy the file.
Multiple environments
Each environment needs its own WordPress salt. Production, staging and local each need a separate set. A shared set across environments 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.
curl "https://api2.globus.studio/v2/salt?seed=ci-test&format=php"Read the endpoint documentation for the response format.
A rotation checklist
Take a backup of wp-config.php. Generate a new set. Replace the eight lines. Load the login page in a private window. Sign in with an administrator account. Check that a normal page loads and that a form with a nonce submits. If something fails, restore the backup and investigate before trying again.
After the rotation, tell the team that sessions were reset. A support queue full of "I was logged out" tickets is easier to handle when the change is expected.
Keep a note of the date and the reason. The next person who has to rotate the salts will want to know which values are current and which file was replaced. A password manager entry or a private change log is enough.
Related reading
Each run of the WordPress salt generator should feed one environment. After a rotation, review the admin passwords with the password generator. If the site accepts logins from anywhere, read why a User-Agent is not proof before you add a block rule.
Further reading: WordPress security keys.