WordPress Salts 101: Everything You Need to Know

You usually notice WordPress salts when you are already worried about WordPress security. You open wp-config.php, see a block of long random strings, and wonder if you should change them, hide them, or leave them alone.

Here is the short answer: most healthy WordPress sites already have salts in place. You should change them when the secrets may be exposed or untrusted, not just because a checklist says so.

Change them after a hack, exposed config file, leaked backup, public repository mistake, or placeholder values. Use the official WordPress salt generator or a trusted security workflow, and expect every logged-in user to be logged out.

Understand WordPress salts

What WordPress salts are

WordPress salts are secret random strings used by WordPress for security checks. People often say salts, salt keys, and security keys together because they sit in the same part of wp-config.php.

A normal WordPress site has eight values:

You do not need to memorize these names. The practical point is simpler: they are site secrets. Do not share them in screenshots, support threads, tickets, public repos, or shared notes.

It is wise to use different salts for every site. Reusing one set across production, staging, and another site turns one leak into a wider problem.

What WordPress salts do

WordPress uses salts and security keys when it creates trusted security hashes. For most site owners, that mainly affects WordPress cookies and nonces.

A login cookie lets WordPress remember that a user is already signed in. A nonce is a short-lived token WordPress uses to check actions such as saving settings or submitting admin forms.

If the salts change, WordPress stops trusting cookies and nonces made with the old salts. That is why users get logged out after a salt change.

This is useful, but narrow. WordPress salts do not clean malware, stop brute-force attacks, fix weak passwords, or protect an admin account whose password is already known. They help WordPress decide whether certain cookies and tokens can be trusted.

That distinction matters after a hack. Salt rotation can help end old sessions, but it is not a cleanup plan by itself.

Where to find WordPress salts

Most sites store WordPress salts in wp-config.php, usually in a section named Authentication Unique Keys and Salts. Because this file contains secrets, make sure you also secure your wp-config.php file.

Some hosts manage this file for you. Some advanced setups load salts from environment variables or another config file. If you cannot find them, check your host documentation before editing random files.

If the values still say put your unique phrase here, replace them. Placeholder text is not a secret.

Before you edit wp-config.php, make sure you have:

• a current backup
• working file access through SFTP, SSH, or your host file manager

A broken quote, missing parenthesis, or pasted block in the wrong place can bring the site down. The task is small, but the file is sensitive.

Decide when to change WordPress salts

When to change WordPress salts

Change salts when the old values may no longer be private. Do not rotate them on a fixed schedule just to feel more secure.

The clearest rule is this: rotate salts when trust is broken. If nothing was exposed and the site is healthy, spend your time on updates, backups, login protection, two-factor authentication, and malware scanning.

What happens after you change WordPress salts

Changing salts does not change usernames or passwords. It changes what WordPress trusts.

Expect these effects:

• logged-in users must log in again
• old admin actions may fail until the page is refreshed
• cached forms may need cache clearing or a fresh page load
• checkout, member login, course access, and account pages should be tested
• some plugins may need attention if they used WordPress salts to encrypt stored settings

That last point is uncommon for simple sites, but it matters on complex ones. Some plugins use WordPress salts when storing API keys, mail settings, two-factor authentication seeds, or integration secrets. If those settings stop working after rotation, check the plugin settings before assuming the whole site is broken.

For a small blog, salt rotation is often a short logout event. For a busy store or membership site, schedule it when fewer users are active.

Changing WordPress salts safely

Start with the reason for the change. A hacked site needs a different path than a healthy site with placeholder values.

Use a security workflow if the site may be hacked

If you are changing salts because of a hack, suspicious admin activity, or exposed files, clean the site first. If malware still has file access, it can read the new salts as soon as you save them. Use this order:

• Scan the site for malware and suspicious changes before rotating anything.
• Remove malware from your WordPress site so the attacker cannot read the new secrets.
• Remove unknown admin users and review access because salts do not fix stolen passwords.
• Update vulnerable plugins, themes, and WordPress core to close the entry point.
• Rotate WordPress salts and security keys after the site is clean.
• Reset affected passwords and strengthen login protection so old access cannot be reused.
• Enable firewalling, backups, and monitoring to catch the next problem earlier.

MalCare fits this case because salt rotation belongs inside a broader recovery workflow. The goal is to scan, clean, harden, and monitor the site, not just replace eight lines in a config file.

Use a plugin for simple rotation on a healthy site

A plugin such as Salt Shaker can regenerate salts from the WordPress dashboard. Use this when the site is healthy, you have admin access, and you want to avoid editing wp-config.php manually.

Be careful with scheduled rotation. It can log users out at awkward times and may create support issues without adding much protection.

Skip this route if the site is compromised. A plugin running inside a hacked WordPress install is not the right first move.

Replace salts manually with the official generator

Manual replacement is the standard method when you can edit the wp-config.php file safely.

Use the official WordPress.org secret-key generator: https://api.wordpress.org/secret-key/1.1/salt/

It creates a fresh block of security keys and salts. Generate a new block for each site. Do not reuse values.

Follow these steps:

• Backup the site before editing the config file so you can recover from a bad paste.
• Confirm you can reopen or restore wp-config.php through SFTP, SSH, or your host file manager.
• Open the official WordPress salt generator and keep the generated values private.
• Find the Authentication Unique Keys and Salts block in wp-config.php.
• Replace the full existing block with the generated block without changing nearby database settings.
• Save the file and log in again because your current session will be invalid.
• Test important site flows after the change including admin save actions, forms, checkout, account pages, and plugin integrations.
• Clear cache if forms or admin actions fail after rotation.

Do not invent your own random-looking strings. Also do not paste generated salts into AI prompts, public tickets, screenshots, or shared documents. They should move from the generator to your config file, then stay private.

Use WP-CLI if you’re familiar with it

Developers and server admins can run wp config shuffle-salts with WP-CLI.

Use this only when you already manage the site through SSH and understand the config layout. If your host stores salts outside the normal file, or your deployment uses environment variables, check that setup first.

The command is convenient. It still changes production secrets, so test the site afterward.

Which WordPress salt generator to use

Use the official WordPress.org generator for real sites. Third-party generators may explain what salts look like, but production secrets should come from WordPress.org or trusted command-line tooling. Keep these rules:

• generate fresh salts for every site
• use different values for staging and production
• do not store salts in shared notes
• do not publish screenshots that show them
• do not keep old values in a public repository

If a salt value has been exposed, replace it. Treat it like any other leaked secret.

What to do after changing salts

Test the site as a user, not just as an admin who wants the task finished.

• Log back in as an administrator and confirm the dashboard loads.
• Save a normal setting to check admin actions.
• Submit an important form to catch nonce or cache issues.
• Test checkout, member login, course access, or account pages if the site has them.
• Check plugin settings that connect to outside services such as email, analytics, payment, or security tools.
• Ask another user role to log in if the site has editors, customers, members, or students.
• Clear cache and retry failed forms before assuming the edit broke the site.

If this was part of hack recovery, keep going. Review admin users, reset affected passwords, patch vulnerable software, enable login protection, and keep backups current.

If the site was healthy, this is not a crisis. Confirm the salts are unique, keep them private, and focus on the controls that prevent the next issue.

Final advice on WordPress salts

WordPress salts are worth understanding because they sit close to login security. They are also easy to overrate.

Change them when the old values may be exposed, weak, or untrusted. Do not rotate them just because it feels productive.

If your site was hacked, clean it first, rotate salts, reset affected access, patch vulnerable software, and harden login security. If your site is healthy and already has unique salts, keep them private and move on to the security work that blocks the next problem.

FAQs