Salt Generator

A cryptographic salt is a random sequence of bytes added to a password (or other data) before it is passed through a hashing function. The salt is stored alongside the resulting hash so it can be re-applied during authentication. Because every user gets a unique salt, two users with the same password will have completely different stored hashes, making mass-cracking attacks impractical.

Salts were introduced specifically to defeat precomputed attacks such as rainbow tables — giant lookup tables that map common passwords to their hashes. When a salt is mixed in, an attacker would need a separate rainbow table for every possible salt value, an astronomically large task. A 16-byte random salt creates 2¹²⁸ possible variations, rendering precomputed lookups useless.

It is important to distinguish a salt from a pepper (a secret key added server-side) and from a nonce (a value used only once for encryption). A salt is stored in plain text next to the hash; its job is uniqueness, not secrecy. Security comes from the one-way nature of the hash function combined with the salt's randomness.

Modern password-hashing algorithms such as bcrypt, scrypt, Argon2, and PBKDF2 all incorporate salt internally or accept it as a parameter. This salt generator lets you produce secure salts in multiple output formats so you can use them with whichever algorithm or library your project requires.

This tool uses the browser's built-in Web Cryptography API (crypto.getRandomValues()) to fill a Uint8Array with the requested number of cryptographically secure random bytes. This is the same entropy source used by modern operating systems and is suitable for security-critical applications.

Once the raw bytes are generated, they are encoded into your chosen output format. The generator reports the salt's size in both bytes and bits so you can immediately verify it meets the entropy requirements of your chosen algorithm. Generating multiple salts at once (up to 20) is useful for batch provisioning of test accounts or seeding a database migration.

Salt length is measured in bytes, and each byte contributes 8 bits of entropy. Longer salts are harder for attackers to brute-force but cost a few extra bytes of storage — a negligible price given the security gain. The table below summarises common recommendations:

For most web applications a 16-byte (128-bit) salt is the practical minimum. Security-conscious systems and those handling sensitive data (healthcare, finance) should prefer 32 bytes (256 bits). The 8-byte option exists for legacy compatibility only and should be avoided in new projects.

This salt generator supports five output encoding formats. The underlying random bytes are identical regardless of format; only the representation changes. Choose the format that your library, database column, or configuration file expects.

• Hexadecimal — Each byte becomes two lowercase hex characters (0–9, a–f). A 16-byte salt produces a 32-character string. Hex is the most universally supported format and is the default in many hashing libraries.
• Base64 — Groups three bytes into four ASCII characters using the standard alphabet (A–Z, a–z, 0–9, +, /). Output is padded with = to a multiple of four characters. A 16-byte salt encodes to 24 characters. Use this where compact text is important.
• Base64 URL — Identical to Base64 but replaces + with -, / with _, and omits padding. This is safe to embed directly in URLs and JSON Web Tokens (JWTs) without percent-encoding.
• Byte Array — Outputs the decimal value of each byte (0–255) separated by commas, e.g., 42, 197, 8, …. Handy for populating byte-array literals in Java, Go, or C# source code.
• Binary — Each byte is printed as an 8-digit binary string (e.g., 00101010), separated by spaces. Useful for educational demonstrations or low-level debugging.

When storing salts in a SQL database, hexadecimal in a VARCHAR(64) or CHAR(64) column is the most portable choice. For NoSQL stores or REST APIs, Base64 URL fits naturally inside JSON fields and Authorization headers without escaping.

Generating a salt correctly is only the first step. How you store, transmit, and use the salt determines the overall security of your password storage system. Follow these principles to avoid common pitfalls.

Always use a CSPRNG. This generator uses crypto.getRandomValues(), a cryptographically secure pseudo-random number generator (CSPRNG). Never use Math.random() or language-level rand() functions for security purposes — they are not designed to resist prediction.

Never reuse salts. Each password, each account, and each hashing event must receive a freshly generated, independent salt. Reusing salts across users partially defeats the purpose, because two users with the same password would again share the same hash.

Store the salt alongside the hash. The salt is not secret; it must be retrievable during login to re-derive the hash for comparison. Most libraries (e.g., bcrypt in Node.js) automatically embed the salt in the hash output string, so you store a single field. If you manage salts manually, keep a dedicated salt column in your users table.

Do not confuse salt with secret key material. If you need server-side secrecy, add a pepper — a secret value stored in an environment variable or secrets manager, not in the database. The salt handles uniqueness; the pepper adds confidentiality at the application layer.

Use a memory-hard hashing algorithm. Salts are most effective when paired with bcrypt (cost ≥ 12), scrypt, or Argon2id. Fast hash functions like MD5 or SHA-1 are unsuitable for passwords even with a salt, because GPUs can trial billions of guesses per second.

Most modern hashing libraries handle salt generation internally, but understanding the underlying process helps you audit and configure them correctly. Below are common integration patterns.

In Node.js with bcrypt, the library generates a 16-byte salt automatically when you call bcrypt.hash(password, saltRounds). If you need an explicit salt for custom workflows, you can call bcrypt.genSalt(rounds) which returns a salt string you can inspect or store separately.

In Python with passlib, algorithms like argon2 and bcrypt auto-generate salts; you rarely handle them manually. For lower-level use with hashlib.scrypt() or hashlib.pbkdf2_hmac(), pass os.urandom(16) or os.urandom(32) as the salt parameter.

In Java, SecureRandom.nextBytes(byte[] salt) fills a byte array suitable for passing to javax.crypto.spec.PBEKeySpec or Spring Security's BCryptPasswordEncoder.

When working with JWT or API tokens, generate a Base64 URL salt to use as the random component of a token ID. This ensures tokens are unique across re-issuances even if user state has not changed.

For database migrations, use the quantity slider to generate a batch of salts upfront, then assign one per row in your migration script. This avoids making repeated network or OS calls inside a transaction loop.