API key generator

Generate random API keys in base62, hex or base64url, with an optional prefix and the SHA-256 hash to store on your server.

How to use

Choose a format and a strength, add a prefix if you want one, and Generate creates the key with crypto.getRandomValues(), the browser’s cryptographic random generator. Copy next to a key copies that key; Copy all puts every key on the clipboard, one per line. Up to 20 keys at a time, each drawn independently.

The strength is the number of random bits, and the length follows from the alphabet. At 256 bits a hexadecimal key has 64 characters, while base62 (a–z, A–Z, 0–9) and base64url (which adds - and _) need 43. Each base62 character is drawn from one random byte, and bytes from 248 up are thrown away, so all 62 characters are exactly equally likely; the line above the keys shows the real number of bits.

A prefix such as sk_live_ is written in front of the random part as it is. It is not secret and adds no strength, but it tells a person what the key is for, and it lets secret scanners spot a leaked key in code: Stripe’s keys start with sk_, pk_ or rk_ followed by test_ or live_, and GitHub’s tokens with ghp_, gho_ and similar. An underscore also keeps the whole key selected on a double-click.

With the SHA-256 option each key comes with its hash, computed over the whole key, prefix included. Store only that hash on the server: when a request arrives, hash the key it carries and compare. Because the key is long and random, a fast hash is enough here, unlike passwords, which need a slow one. Nothing is sent anywhere; the keys exist only on this page until you copy them.

Example

Generates one 256-bit base62 key with the prefix sk_test_. Each run produces a different key.

256 bits in base6243 letters and digits: 43 × 5.95 bits ≈ 256 bits.
256 bits in hexadecimal64 characters from 0–9 and a–f: 4 bits each.
128 bits in base64url22 characters, 132 bits: base64url can only round up to whole 6-bit characters.
Prefix sk_test_sk_test_ followed by the random part; the prefix adds 8 characters and no strength.

Frequently asked questions

How many bits does an API key need?

128 random bits are already far beyond guessing: even at a billion attempts per second, covering a noticeable fraction would take longer than the age of the universe. 256 bits is the default here because a longer key only costs a few characters. GitHub moved its tokens to 178 bits in 2021.

Which format should I choose?

Base62 is the easiest to copy: no symbols that a URL, a shell or a configuration file might treat specially. Hexadecimal is longer but works where only 0–9 and a–f are accepted. base64url is the shortest and safe in URLs, but the - can break double-click selection and some validators reject it.

Why store only the hash?

If the database leaks, the hashes cannot be used to call your API, and the keys cannot be worked out from them. It is the same idea as with passwords; the difference is that a random 256-bit key cannot be guessed, so SHA-256 is enough and a slow hash such as Argon2 is not needed.

Is a UUID good enough as an API key?

A version 4 UUID has only 122 random bits and a fixed, recognisable shape, and it was designed as an identifier rather than a secret. For keys that grant access, use a dedicated random key like these, with a prefix if you want it to be recognisable.

When do I need 384 or 512 bits?

For secrets that sign JSON Web Tokens with HMAC. RFC 7518 requires a key at least as long as the hash output: 256 bits for HS256, 384 for HS384 and 512 for HS512. For an ordinary API key, 256 bits is already more than enough.