API Key Length: How Long Should Your API Key Be?
The length of an API key is not arbitrary. It directly determines the key's entropy, which defines how resistant it is to brute-force attacks. But "length" alone is misleading — the encoding format matters just as much. A 32-character hex key and a 32-character base64 key have very different security properties.
This guide gives you a definitive answer: how long your API key should be, why, and how to calculate the entropy for any format.
The Short Answer
For most APIs, use 32 bytes of random data (256 bits of entropy), encoded as a 64-character hex string or a 43-character base64url string. This matches AES-256 security strength and is resistant to all known brute-force attacks.
If you want a minimum viable key, 16 bytes (128 bits / 32 hex characters) is the floor. Below 128 bits, your keys may be vulnerable to well-resourced attackers within the key's lifetime.
Key Length vs Entropy
The security of a key is measured in bits of entropy, not in the number of characters. Entropy depends on both the number of characters and the size of the character set (alphabet).
The formula is: entropy = length x log2(alphabet_size)
| Encoding | Alphabet Size | Bits per Char | Chars for 128-bit | Chars for 256-bit |
|---|---|---|---|---|
| Hex (0-9, a-f) | 16 | 4 | 32 | 64 |
| Base64 | 64 | 6 | 22 | 43 |
| Alphanumeric (a-z, A-Z, 0-9) | 62 | 5.95 | 22 | 43 |
| Base62 + symbols | 94 | 6.55 | 20 | 39 |
| Lowercase hex (0-9, a-f) | 16 | 4 | 32 | 64 |
This table reveals a critical insight: a 32-character base64 key has 192 bits of entropy (32 x 6), while a 32-character hex key has only 128 bits (32 x 4). Same length, 50% more security. Encoding matters.
What the Industry Uses
Examining the key lengths of major API providers reveals a strong consensus around 128-256 bits of entropy:
| Provider | Key Format | Total Length | Estimated Entropy |
|---|---|---|---|
| Stripe | sk_live_ + 24 base62 chars | 32 chars | ~143 bits |
| OpenAI | sk-proj- + 48 base62 chars | 56 chars | ~285 bits |
| AWS Access Key | 20 alphanumeric chars | 20 chars | ~119 bits |
| GitHub PAT | ghp_ + 36 base62 chars | 40 chars | ~214 bits |
| Google Cloud | 39 alphanumeric chars | 39 chars | ~232 bits |
| Twilio | 32 hex chars | 32 chars | 128 bits |
Notice that every provider delivers at least 119 bits of entropy, and most target 128-256 bits. No serious API uses keys shorter than 20 characters.
Minimum Length by Security Requirement
128 bits (minimum for production)
At 128 bits of entropy, an attacker performing one trillion (10^12) guesses per second would need approximately 5.4 x 10^15 years to try every possible key. This exceeds the age of the universe by a factor of about 400,000. For most APIs with rate limiting and monitoring, 128 bits is sufficient.
- 32 hex characters
- 22 base64 characters
- 22 alphanumeric characters
192 bits (comfortable margin)
192 bits provides a safety margin against future advances in computing. It is the entropy level used by AES-192 and is commonly used for long-lived keys that may be active for years.
- 48 hex characters
- 32 base64 characters
- 33 alphanumeric characters
256 bits (recommended for production)
256 bits matches AES-256 and is considered secure against quantum computing attacks (Grover's algorithm reduces effective entropy to 128 bits, which remains unbreakable). This is the recommended length for any key that protects sensitive data or financial transactions.
- 64 hex characters
- 43 base64 characters
- 43 alphanumeric characters
The Prefix Question
Modern APIs include a prefix like sk_live_ or ghp_ before the random portion. The prefix does not contribute to entropy — it is a fixed, predictable string. When calculating your key's security, only count the random characters after the prefix.
// Total length: 40 characters
// Prefix: "sk_live_" (8 chars, 0 bits entropy)
// Random: 32 alphanumeric chars (~190 bits entropy)
// Effective entropy: ~190 bits
sk_live_EXAMPLE_DO_NOT_USE_1a2b...The prefix is valuable for identification, routing, and secret scanning — but it adds zero security. Design your key length around the random portion, then add the prefix on top.
When Keys Are Too Long
There is such a thing as too long. Keys beyond 256 bits of entropy provide no additional practical security (the heat death of the universe arrives long before a 256-bit key is brute-forced). Extra length just creates usability problems:
- Harder to copy-paste without errors
- May exceed HTTP header size limits (typically 8KB per header)
- Increases storage and bandwidth costs marginally
- More likely to be truncated by logging systems
The sweet spot is 32-64 characters of random data (128-256 bits), plus an optional prefix of 4-12 characters.
When Keys Are Too Short
Keys under 128 bits of entropy are dangerous. Here is what an attacker can do with modern hardware:
| Entropy | Brute-force Time (1T guesses/sec) | Verdict |
|---|---|---|
| 64 bits | ~5 hours | Broken trivially |
| 80 bits | ~38 years | Risky for long-lived keys |
| 96 bits | ~2.5 million years | Borderline acceptable |
| 128 bits | ~5.4 x 10^15 years | Secure |
| 256 bits | ~3.7 x 10^54 years | Overkill (in the best way) |
A 64-bit key can be cracked in hours with a GPU cluster. An 80-bit key might survive decades but offers no margin for error. Start at 128 bits minimum.
Practical Recommendations
- Default to 32 bytes (256 bits) encoded as hex (64 chars) or base64url (43 chars)
- Add a prefix of 3-8 characters (e.g.,
sk_,pk_,api_) to aid identification - Never go below 16 bytes (128 bits) for any key used in production
- Use base64url over hex if you want shorter keys with the same entropy
- Document your key format in your API docs so users know what to expect
- Generate keys server-side with a CSPRNG, never client-side for authentication
For quick key generation with any length, try our free API key generator which lets you set the exact character count and format.
Recommended Resources
To understand why key length maps to security strength, Real-World Cryptography covers entropy, AES key sizes, and brute-force resistance in depth. For securing keys in web applications, The Web Application Hacker's Handbook shows how attackers exploit short keys.