API Key Generator
Generate API keys and secrets the way modern platforms do: a readable prefix, a crypto-random body with a chosen number of bits and an optional checksum, plus the SHA-256 hash you should store instead of the key.
Generated keys
Check a key
How to use the API Key Generator
- Choose a format: Base62 is compact and copy-friendly, hex is universal, Base64url packs the most bits per character.
- Pick the strength in bits (256 is a good default) or type an exact length.
- Add a prefix such as
sk_live_and decide on a checksum or grouping. - Press Generate Keys, then copy single keys or export them all as .txt, .env, JSON or CSV.
- Store only the SHA-256 hash on your server and show the key to the user once. Use the checker to validate keys later.
Anatomy of a modern API key
Many platforms now use keys made of three parts, for example sk_live_edblw91dbgYb3B9AsPvJSkkfSQR8CtkWCnyLQBkqewL0oZJzF:
| Part | Example | Purpose |
|---|---|---|
| Prefix | sk_live_ | Says what the key is (secret / publishable) and where it works (live / test). Makes leaked keys easy to spot and scan for. |
| Random body | 43 Base62 characters | The secret part: 43 × log2(62) = 256.0 bits of entropy from a cryptographic random generator. |
| Checksum | 6 Base62 characters | CRC32 of everything before it, written in Base62. Detects typos and lets scanners ignore random look-alikes. Not secret. |
To validate the checksum in your own code: take the key without its last 6 characters (and a trailing - if you used grouping), compute the standard CRC-32 (IEEE, the same as zlib's crc32), convert the number to Base62 with the alphabet 0-9A-Za-z and left-pad it with 0 to 6 characters.
Key length for each format
| Format | Bits per character | 128 bits | 256 bits | 512 bits |
|---|---|---|---|---|
| Hex | 4.000 | 32 chars | 64 chars | 128 chars |
| Base32 | 5.000 | 26 chars | 52 chars | 103 chars |
| Base62 | 5.954 | 22 chars | 43 chars | 86 chars |
| Base64url | 6.000 | 22 chars | 43 chars | 86 chars |
| UUID v4 | – | always 36 chars with 122 random bits | ||
Length = ⌈bits ÷ log2(alphabet size)⌉. The tool rounds up, so the entropy shown can be a little above the target (for example 22 Base62 characters give 131.0 bits).
Storing and checking keys safely
- Generate the key, show it to the user once and never log it.
- Store SHA-256(key) together with the prefix and the last 4 characters for display (for example
sk_live_…ZJzF). - On each request, verify the checksum first (cheap rejection of garbage), then hash the presented key and look the hash up with a constant-time comparison.
- Support several active keys per account so keys can be rotated without downtime, and let users revoke them.
A fast hash is fine for API keys because they carry 128+ bits of randomness, which cannot be brute-forced. Human-chosen passwords are different and need a slow hash such as bcrypt or Argon2.
Frequently asked questions
How many bits should an API key have?
At least 128 bits of entropy, which makes guessing impossible in practice. 256 bits is a common choice and matches the key size of HMAC-SHA256 and AES-256. The entropy card shows the exact figure for your settings; the prefix and checksum do not add any.
Why add a prefix to an API key?
A prefix such as sk_live_ tells people and tools what the key is for and which environment it belongs to. It makes leaked keys easy to recognise in logs and lets secret-scanning tools find them in code repositories.
What is the checksum for?
The last 6 characters can be a CRC32 checksum of the rest of the key, encoded in Base62. Your API can reject mistyped or truncated keys without a database lookup, and scanners can tell real keys from random look-alikes. The checksum is not secret and adds no security.
Should I store API keys in my database?
Store a hash instead. Because API keys are long and random, a fast hash like SHA-256 is enough (unlike passwords, which need bcrypt or Argon2). When a request arrives, hash the presented key and look the hash up. The tool shows the SHA-256 hash of each key for this purpose.
Which format should I choose?
Base62 (0–9, A–Z, a–z) is compact and selects with a double-click. Hex is accepted everywhere but longer. Base64url is the shortest but includes - and _. Base32 is case-insensitive, which helps when keys are read aloud. UUID v4 has a fixed 122 bits.
Are the keys generated securely and privately?
Yes. Keys come from crypto.getRandomValues with rejection sampling, so every character is equally likely. Everything runs in your browser and no key is sent or stored anywhere.