API key & secret key generator
Random API keys, bearer tokens, JWT signing secrets and hex keys straight from the Web Crypto API. Choose the size, encoding and prefix; nothing is sent to a server.
Good practice for API keys and secrets
- Use 256 bits. Brute force is out of the question at 128 bits; 256 leaves margin and matches HS256’s requirement.
- Hash before storing. Keep
SHA-256(key)in the database, show the key once, and compare hashes on each request. The hash generator computes SHA-256 locally. - Prefix for scanning. A distinctive prefix lets GitHub secret scanning and your own log filters catch leaks.
- Never commit secrets. Keep them in environment variables or a secrets manager, and rotate any key that touched a public repo.
- Scope and expire. Give each key the least access it needs and an expiry date where the platform supports it.
Command-line equivalents
openssl rand -hex 32 gives 32 random bytes as hex; openssl rand -base64 32 as Base64. In Node.js: crypto.randomBytes(32).toString('base64url'). In Python: secrets.token_urlsafe(32).
Questions people ask
How long should an API key be?
At least 128 bits of randomness, and 256 bits costs nothing extra. That is 32 random bytes: 64 hex characters, 43 Base64url characters or 43 Base62 characters.
How long should a JWT secret be?
For HS256, RFC 7518 requires a key at least as long as the hash output: 256 bits (32 bytes). Use 48 bytes for HS384 and 64 bytes for HS512. A human-chosen word or sentence is not an acceptable HMAC secret.
Why do some API keys have a prefix like sk_live_?
A readable prefix tells people and secret scanners what the key is for and where it came from. GitHub’s token formats (ghp_, gho_) and Stripe’s (sk_live_, pk_test_) let leaked keys be detected automatically in code and logs. The prefix adds no security; the random part does.
Should I store API keys in my database as-is?
Store only a hash of each key, such as SHA-256, and show the full key to the user once. Because API keys are long and random, a fast hash is fine here; slow hashes like bcrypt are for low-entropy human passwords.
Is it safe to generate production secrets in a browser?
The bytes come from crypto.getRandomValues, the operating system’s CSPRNG, and nothing is transmitted. Many teams still prefer generating production secrets on the server that uses them, for example with openssl rand -hex 32, so the secret never passes through a clipboard.