API key · random bytes
API Key Generator
Generate API keys from cryptographically secure random bytes, encoded as hex or base64url, with an optional prefix such as sk_ or api_.
•••••••••••••••••••••••••••••••••••••••••••
Save this key securely. Treat API keys like passwords. It exists only in this tab: we never send or store it. Keep it in a secret manager or environment variable, never in source control or front-end code.
Letters, digits, "_" and "-". A prefix labels the key; it adds no randomness.
Generated in your browser with crypto.getRandomValues(). Nothing is sent or stored. Verify it
How a Secure API Key Is Made
A good API key is random bytes first and text second. This tool asks crypto.getRandomValues() for the number of bytes you choose - 32 by default, which is 256 bits - and only then encodes them as hex or base64url. The encoding changes how the key looks, not how hard it is to guess.
A prefix such as sk_, pk_ or api_ is added in front as plain text. It tells people and scanning tools what kind of key they are looking at; it adds no randomness.
Secret Key Generator
The same random bytes make a good secret key for things that are not API keys: a session or cookie-signing secret, a webhook signing secret, or the key for an HMAC. Choose 32 bytes for a 256-bit key - the size HMAC-SHA256 needs - or 64 bytes for HMAC-SHA512, and leave the prefix empty. For JSON Web Tokens, the JWT secret generator shows which HS algorithms a length satisfies.
When your own code creates encryption keys, prefer the Web Crypto API's crypto.subtle.generateKey(), as MDN recommends: it can keep the key non-extractable, so it never has to exist as text at all.
Treat API Keys Like Passwords
Anyone who has the key can call the API as you. The OWASP Secrets Management Cheat Sheet gives the essentials:
- Never commit keys to source control. Keep them out of code and config files, and use a pre-commit hook or secret scanner to catch mistakes.
- Keep server-side keys on the server. Anything shipped to a browser or a mobile app can be read by its users.
- Store keys in a secret manager rather than in plain files; environment variables are common, but avoid baking them into container images.
- Use least privilege where the service supports scoped keys, and rotate keys regularly.
- If a key leaks, revoke it first, then issue a new one and remove the old one from the exposed system.
This page never sends or stores the keys it generates, and the copy button clears your clipboard after 30 seconds. Clipboard-history tools on your device may still keep a copy.
API Key Generator FAQs
How many bytes should an API key have?
32 random bytes (256 bits) is the default here and far more than anyone can guess. Longer keys cost nothing in security but take more space; shorter than 16 bytes is not offered.
Hex or base64url?
Both carry the same randomness. Base64url is shorter - 43 characters for 32 bytes instead of 64 in hex - and uses only letters, digits, - and _, so it is safe in URLs and headers. Hex is easier to read aloud and compare.
Does a prefix like sk_ make the key weaker?
No, and it does not make it stronger either: the prefix is fixed text added in front. It only labels the key, which helps people and secret-scanning tools recognise it. The random part carries all the security.
Is a UUID good enough as an API key?
No. RFC 9562 warns that UUIDs must not be used as security capabilities. Use random bytes from this generator instead.
What should I do if a key leaks?
Revoke it immediately, issue a new one and remove the old key from wherever it was exposed - the order OWASP recommends. Deleting a commit does not undo a leak: the key may already have been copied.
Related guides
CSPRNG vs Math.random(): Why Secure Password Generators Use Web Crypto
