Salt Generator

1. Pick a size. 16 bytes (128 bits) is the usual choice and is already selected.
2. Pick the format your code or config file expects: Hex, Base64, URL-safe Base64, or Letters & numbers if symbols cause trouble.
3. Copy the salt. Click New salt for another. To make many at once, set How many under Fine-tune and download them as a text file.

A salt is a random value that is mixed into a password before it is hashed. It is stored next to the hash, in plain sight, and its only job is to be different for every password. Each salt here comes from your browser's cryptographically secure random generator, the same source it uses for encryption keys.

Two people sign up to the same site and both choose the password sunshine. Here is what ends up in the database with and without a salt.

16 bytes (128 bits) is the standard answer. It is what bcrypt uses, what the Argon2 standard recommends, and the minimum NIST sets for PBKDF2. At that size, two people getting the same salt by chance is practically impossible. A longer salt does no harm, but it does not make the password any harder to crack.

Watch the units. A setting that says “salt length 16” usually means 16 bytes, which is 32 hex characters, not 16 characters. If a system asks for a salt as text of a certain length, use Letters & numbers: 22 of them carry about the same randomness as 16 bytes.

Hex, Base64 and URL-safe Base64 are three ways of writing the same random bytes as text. Pick whichever your code or config file expects. Here is one 16-byte salt in each:

• Hex is the safest to paste anywhere: only 0–9 and a–f.
• Base64 is shorter, but contains +, / and =, which can break URLs, file names and some config formats.
• URL-safe uses - and _ instead and drops the =, so it is safe in URLs and .env files.
• Letters & numbers is a random string rather than encoded bytes, for systems that take the salt as plain text.

One thing to get right: if your code decodes the salt (from hex or Base64) before hashing, the result is different from using the same characters as text. Both are fine as long as you do it the same way every time.

No. bcrypt, scrypt and Argon2 libraries create a random salt for every password and store it inside the hash string they return. A bcrypt hash like $2b$12$R9h/cIPz0gi.URNNX3kh2O… already holds its 16-byte salt (the 22 characters after the cost). Let the library do it; don't pass your own salt unless you have a specific reason.

A separate salt is what you need for:

• PBKDF2, where your code usually supplies the salt and stores it alongside the hash.
• Deriving an encryption key from a password, where the salt is saved with the encrypted data.
• HKDF and other key derivation, test data, and config files that ask for a random salt value.

Never store passwords as a plain salted hash such as SHA-256 of salt plus password. A salt stops lookup lists, but a fast hash still lets an attacker test billions of guesses a second. Use a slow password hash (Argon2id, scrypt, bcrypt or PBKDF2) and give it the salt.

WordPress uses eight random values in wp-config.php (four keys and four salts) to secure login cookies. The WordPress keys tab makes a fresh set in the same format as WordPress's own generator: 64 random characters each, never containing a quote or backslash that could break the file.

1. Open wp-config.php in your site's root folder, using your host's file manager or SFTP.
2. Find the eight define lines for AUTH_KEY through NONCE_SALT. They may have placeholder text or older random values.
3. Replace them with the eight lines from the tool and save the file.

Everyone who is logged in, including you, is signed out and has to log in again. That is the point: changing the salts after a suspected break-in invalidates any stolen login cookies. Passwords are not affected.

In an app, generate a new salt for each password when it is set, using your language's secure random source. Each of these makes 16 random bytes:

Avoid Math.random(), rand(), timestamps or user IDs as salts. They are predictable or repeat, which defeats the purpose.