Why do passwords need salts?

A salt is unique per-user random data added to a password before hashing. It prevents rainbow-table attacks (pre-computed hashes of common passwords) and means two users with the same password get different hashes. Bcrypt embeds the salt in the hash automatically.

How long should my salt be?

16 bytes (128 bits) is the modern minimum. 32 bytes (256 bits) for high-security applications. Don't go below 8 bytes — too short to provide rainbow-table resistance.

Which encoding should I use?

Hex is most readable and copy-paste safe. Base64 is shorter. Base64url is URL-safe (no + or /). Base32 is human-friendly (no easily-confused chars). The output works identically — pick what fits your storage format.

Is anything sent to a server?

No — uses crypto.getRandomValues in your browser. Output never leaves the page.

salt · hex · base64 · base32 · local

Generate cryptographic salts

Crypto-random salts in hex, base64, base64url, or base32 — for password hashing, KDF inputs, or any place that needs unpredictable per-record bytes.

Cryptographic Salt Generator

Bytes

128 bits

Encoding

hex

format

Count

1 requested

Status

—

web crypto

input · controls

Length (bytes)Count

Recommended: 16 bytes for bcrypt-style salts, 32 for HKDF/PBKDF2 inputs.

Output encoded as hex.

output · salts (0)

Click Generate to mint salts

Quick Start

How to use cryptographic salts

Salts make password hashes per-user unique. Without a salt, identical passwords share the same hash and rainbow tables defeat the whole scheme.

01
Pick byte length
16 bytes (128 bits) suits bcrypt; 32 bytes is generous for HKDF.
Inputs are treated as UTF-8 throughout the pipeline and validated client-side as you type — nothing dispatches until the value is well-formed.
lengthinpututf-8client-sidevalidated
bytes · text16 · set
```
128 bits
```
loaded · parsedclient-side
02
Choose encoding
hex prints widely; base64url is URL/JWT safe; base32 is case-insensitive.
Each toggle re-computes through a memoised hook, so flipping options never resets your input and the UI stays snappy on large inputs.
encoptionslivememoisedtoggles
enc · memoisedhex · live
```
a3f1…
```
options set · memoisedlive
03
Generate
crypto.getRandomValues fills the buffer with crypto-grade bytes.
Randomness — where used — comes from crypto.getRandomValues, never Math.random. Heavy work sits in useMemo.
mintcomputeinstantlocaldeterministic
mint · instantrand · computed
```
32 random bytes
```
computed · instantinstant
04
Combine with password
Hash(password || salt) — store the salt alongside the hash.
Copy writes through navigator.clipboard and downloads use a Blob — zero network traffic. Same input plus same options always yield the same bytes.
usecopydownloadzero-networkreproducible
ok · copiedstore · copied
```
Copied
```
shipped · ready to shipsuccess

Pro tips

Pro tips for everyday utilities

Reach for crypto.getRandomValues

Cryptographically random for IDs, tokens, salts. Math.random is for animation and games, not security.

Sort IDs lexicographically

UUID v4 has no time ordering. Use ULID or UUID v7 if you need sorted IDs.

Mock data with seeds

Faker-style libraries can be seeded so tests are reproducible. Embed the seed in the fixture file.

Reference cards beat memory

Cheatsheets for Vim, Git, Docker, Linux signals are faster than man pages when you’re mid-flow.

Browser APIs vary

Touch events, gamepads, and clipboard differ across vendors. Feature-detect before use.

Persist in the right place

localStorage for user preferences, sessionStorage for transient state, IndexedDB for structured data.

Use Cases

When to use salts

Password hashing, KDFs, nonces, dev fixtures.

Password hashing

Per-user salt makes rainbow tables useless. Random values come from crypto.getRandomValues — cryptographically secure for tokens, salts, and session IDs. Math.random is deterministic enough for animations but predictable enough to be a security bug.

CSPRNG-backed

KDF inputs

Salt + password into HKDF or PBKDF2 derive a strong key. Pair with hashids, ULID, or UUID v7 when you need both random and sortable — useful for primary keys, public-facing IDs, and event log ordering without a sequence column.

reproducible

Database nonces

Per-row randomness for AEAD encryption. Output is deterministic given the same seed, so fixtures and tests stay reproducible across CI runs and contributor machines. Embed the seed in the fixture file for full replay.

snappy

Token IDs

Random server-side session identifiers. Heavy work runs through useMemo so the UI stays snappy on large inputs. Same input + same options yields identical bytes — the kind of stability snapshot tests rely on.

feature-detected

API keys

Generate opaque developer credentials. Storage tools persist to the right backend: localStorage for user preferences, sessionStorage for transient state, IndexedDB for structured data. Pick the right shelf and quota worries disappear.

deterministic

Dev fixtures

Realistic random bytes for test data. Browser feature detection: clipboard, fullscreen, gamepad, and Web Bluetooth APIs gracefully fall back when unavailable. No surprise white screens on Safari or older Firefox.

production-ready

FAQ

Frequently asked questions

How long should a salt be?

OWASP recommends at least 16 bytes (128 bits) for password hashing. More is fine — diminishing returns past 32.

Hex, base64, or base32?

Hex is widely supported; base64url is URL-safe and 33% shorter; base32 is case-insensitive (great for typed input).

Can I reuse salts?

Never reuse salts across passwords. The whole point is per-record uniqueness.

Do salts need to be secret?

No — they're stored alongside the hash. They just need to be unpredictable per record.

Does it run locally?

Yes — bytes come from crypto.getRandomValues in your browser. Nothing is sent to a server.

Suggest a tool

Something missing?

Tell us what you need. We ship the top requests every two weeks.

47 in queue·8 shipped this month

Request queued. Thanks!