32-character password generator
32 characters. For secrets machines keep.

Service accounts, database passwords, app secrets and encryption keys are typed by no one and kept in a vault, so there is no reason to keep them short. Thirty-two random characters carry more than 200 bits: brute force is simply off the table.

Very strong

Calculating…

Time to crack your 32-character password

Measuring…

Worst case: an offline attack on a fast hash by a GPU cluster testing one trillion guesses per second.

You are here
  1. 1 second
  2. 1 hour
  3. 1 year
  4. A lifetime
  5. The pyramids
  6. Since the dinosaurs
  7. Age of the universe

The numbers

Past astronomical: 32 characters by the numbers.

Even 32 random digits would outlast the universe against a GPU cluster. With letters, numbers and symbols, the figures stop meaning anything at all.

32 random charactersEntropyGPU cluster, fast hashGPU rig, bcrypt
Numbers only 0-9106 bits1.6 trillion years1.6 × 1019 years
Lowercase a-z150 bits3 × 1025 years3 × 1032 years
Upper and lower a-z A-Z182 bits1.3 × 1035 years1.3 × 1042 years
Letters and numbers a-z A-Z 0-9191 bits3.6 × 1037 years3.6 × 1044 years
Letters, numbers and symbols + !@#$%206 bits1.8 × 1042 years1.8 × 1049 years

Beyond about 128 bits, extra length changes nothing for brute force. What 32 characters buy is a margin that survives weak hashing, leaked hashes and the hardware of the coming decades.

Where it belongs

Long secrets for things nobody types.

Service accounts and databases

Accounts used by applications, backups and scheduled jobs. Nobody types them, they live in a secret manager or a vault, and they are high-value targets.

App secrets and webhook keys

Session secrets, signing keys and webhook secrets you create yourself. Make one per environment (the Generate 10 button helps) and never commit them to a repository.

Encrypted backups and archives

Passwords for encrypted backups, disk images or 7-Zip archives are attacked offline, with no rate limit at all. This is exactly where a huge margin pays off.

Admin accounts nobody uses daily

Break-glass and root accounts, router and NAS admin passwords: store them in your password manager or a sealed envelope, and make them long.

Copy-safe

Secrets that survive config files.

Symbols such as #, $, &, quotes and backslashes can break .env files, YAML, shell commands and connection strings. Switch symbols off in the generator above: 32 random letters and digits still carry about 190 bits.

On a server or in a script, these one-liners give a 32-character secret of the same quality from your system's random generator:

openssl rand -base64 24
python -c "import secrets; print(secrets.token_urlsafe(24))"
[Convert]::ToBase64String([Security.Cryptography.RandomNumberGenerator]::GetBytes(24))

The first two work on Linux and macOS (and on Windows with OpenSSL or Python installed), the last one in PowerShell 7. Each encodes 24 random bytes, or 192 bits, as 32 characters.

Questions

32-character password FAQ

Is a 32-character password overkill?

For a password you type, yes. For a secret that only machines or a password manager handle, no: it costs nothing and takes brute force off the table, even if the hash leaks or was stored with a weak algorithm.

How strong is a 32-character password?

With letters, numbers and symbols, about 206 bits of entropy. A GPU cluster making a trillion guesses per second would need about 1.8 × 10^42 years. Letters and digits only still give about 190 bits.

Should a 32-character password include symbols?

Not necessarily. At 32 characters, symbols add little strength and can break .env files, URLs and shell commands. Letters and digits only are a safe choice for secrets you paste into code or configuration.

Is a 32-character password the same as a 256-bit key?

No. Each random character from this generator's 87-character set carries about 6.4 bits, so 32 of them give about 206 bits, and a 32-character hex string only 128 bits. A true 256-bit key needs 43 base64 characters or 64 hex characters, generated by your crypto library.

Can I use these as API keys or app secrets?

Yes for secrets you create yourself, such as session or webhook secrets: they come from crypto.getRandomValues, the cryptographic generator browsers use for encryption keys. In production, generating secrets inside your secret manager or CI pipeline avoids copying them by hand.