API Key Format Comparison: Hex vs Base64 vs UUID — Which Should You Use?
Choosing the right format for your API keys affects storage efficiency, URL compatibility, developer experience, and even how easily leaked keys can be detected. The three most common formats are hexadecimal, Base64, and UUID. Each has distinct tradeoffs that matter depending on your use case.
This guide compares all three formats across the dimensions that matter most for production API systems.
Quick Comparison Table
| Property | Hex | Base64url | UUID v4 |
|---|---|---|---|
| Characters used | 0-9, a-f | A-Z, a-z, 0-9, -, _ | 0-9, a-f, hyphens |
| Bits per character | 4 | 6 | 4 (with fixed bits) |
| 256-bit key length | 64 chars | 43 chars | N/A (max 122 bits) |
| 128-bit key length | 32 chars | 22 chars | 36 chars (with hyphens) |
| URL safe | Yes | Yes (url variant) | Yes |
| Case sensitive | No | Yes | No |
| Human readable | Moderate | Poor | Good (structured) |
Hexadecimal Keys
Hex encoding represents each byte as two characters from the set 0-9a-f. It is the most straightforward encoding and the easiest to reason about in terms of entropy.
// 256 bits of entropy = 64 hex characters
a3f8c1d9e4b72f6a8d1e3c5b7a9f0d2e4c6b8a1f3e5d7c9b0a2d4f6e8c1a3b5d
// 128 bits of entropy = 32 hex characters
a3f8c1d9e4b72f6a8d1e3c5b7a9f0d2ePros
- Predictable length-to-entropy ratio. 2 characters = 1 byte = 8 bits. Always. No mental math required.
- Case insensitive. No bugs from case-sensitive string comparisons in databases or file systems.
- URL safe by default. No encoding needed for query parameters, headers, or path segments.
- Widely supported. Every language has hex encoding/decoding built in.
- Easy to validate. A simple regex
/^[0-9a-f]+$/confirms the format.
Cons
- Verbose. 64 characters for 256-bit entropy is longer than necessary.
- Storage overhead. Uses 100% more storage than the raw bytes.
Best for
General-purpose API keys, webhook signing secrets, internal service tokens, and any context where simplicity and debuggability matter more than brevity.
Base64url Keys
Base64 encoding uses 64 characters (A-Z, a-z, 0-9, and two symbols) to represent 6 bits per character. The URL-safe variant (RFC 4648) replaces + with - and / with _, and strips padding = characters.
// 256 bits of entropy = 43 base64url characters
o_jB2eS3L2qNHjxbepnwLeTGuKHzPeV8m0otT26Mobtd
// 128 bits of entropy = 22 base64url characters
o_jB2eS3L2qNHjxbepnwLgPros
- Compact. 33% shorter than hex for the same entropy. This matters for HTTP headers with size limits.
- URL safe (when using the url variant). No percent-encoding required.
- Higher information density. Better for bandwidth-constrained environments or storage-sensitive databases.
Cons
- Case sensitive.
AbCdandabcdare different keys. This causes bugs in systems that normalize case. - Easy to confuse standard and URL-safe variants. Mixing them causes authentication failures that are hard to debug.
- Less human-readable. Developers have a harder time visually comparing or recognizing keys.
- Padding ambiguity. Some implementations include
=padding, others strip it. This causes interoperability issues.
Best for
High-throughput APIs where header size matters, mobile applications, JWTs and token-based auth systems, and environments where storage per key is a concern at scale.
UUID v4 Keys
UUID v4 generates 122 random bits formatted as 32 hex digits with 4 hyphens in a standardized pattern: xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx. The 4 indicates version 4 and y is constrained to 8, 9, a, or b.
// UUID v4 — always 36 characters, always 122 bits of randomness
f47ac10b-58cc-4372-a567-0e02b2c3d479Pros
- Universally recognized format. Every developer knows what a UUID looks like.
- Built-in generation in most languages and databases. No custom code needed.
- Structured format. The hyphens make it easier to read, copy, and communicate verbally.
- Database support. Native UUID column types in PostgreSQL, MySQL 8+, and most modern databases with optimized indexing.
- Collision resistance. 122 bits makes collisions astronomically unlikely even at scale.
Cons
- Fixed entropy ceiling. You cannot exceed 122 bits of randomness. For high-security applications requiring 256-bit keys, UUIDs are insufficient.
- Inefficient encoding. 36 characters for only 122 bits of entropy. Hex would need only 31 characters for the same entropy.
- Version and variant bits are predictable. 6 of the 128 bits are fixed, reducing effective keyspace.
- Not suitable as secrets. Many developers treat UUIDs as identifiers rather than secrets, leading to weaker handling practices.
Best for
Public API identifiers (not secrets), resource IDs, correlation IDs for distributed tracing, database primary keys, and any context where developer familiarity and tooling support outweigh entropy requirements.
Entropy Comparison by Format
The following table shows how many characters each format needs to achieve common entropy targets:
| Target Entropy | Hex | Base64url | UUID v4 |
|---|---|---|---|
| 64 bits | 16 chars | 11 chars | N/A |
| 128 bits | 32 chars | 22 chars | 36 chars (max ~122) |
| 192 bits | 48 chars | 32 chars | N/A |
| 256 bits | 64 chars | 43 chars | N/A |
URL Safety Deep Dive
When API keys appear in URLs (query parameters, path segments, or fragments), certain characters cause problems:
- Hex: Always URL-safe. No special characters.
- Standard Base64: Contains
+and/, which must be percent-encoded in URLs. The=padding also needs encoding. - Base64url: Uses
-and_instead, making it URL-safe without encoding. - UUID: Always URL-safe. Hyphens are valid in all URL positions.
If your keys will ever appear in URLs, use hex, base64url, or UUID. Never use standard base64 with
+and/characters.
Storage Efficiency
If you store millions of API keys, the per-key storage adds up. For 256 bits of entropy:
- Raw bytes: 32 bytes
- Hex: 64 bytes (as ASCII/UTF-8)
- Base64url: 43 bytes
- UUID: Cannot represent 256 bits
At 10 million keys, the difference between hex and base64url is about 200MB. In most systems this is negligible, but it matters for in-memory caches and bandwidth-constrained APIs.
Recommendations by Use Case
REST API Authentication Keys
Use hex or base64url with at least 256 bits. Add a prefix like sk_live_ to identify key type and environment. Hex is simpler; base64url is shorter.
Webhook Signing Secrets
Use hex with 256 bits. Webhook secrets are used in HMAC computations where hex is the standard output format, keeping your codebase consistent.
Public API Identifiers
Use UUID v4. These are not secrets, so the 122-bit entropy ceiling is fine. The standardized format makes integration easier for your consumers.
Distributed System Tokens
Use base64url with 256 bits. The compact encoding reduces overhead in service-to-service communication where tokens appear in every request header.
Short-Lived Session Tokens
Use base64url with 128 bits. These tokens expire quickly, so 128 bits is sufficient, and the shorter length improves cookie size efficiency.
No matter which format you choose, always generate the underlying randomness with a cryptographically secure source like crypto.getRandomValues(). The format is just encoding; security comes from the entropy source. Try our free key generator to create keys in any format instantly.
Recommended Resources
For the theory behind encoding, entropy, and cryptographic randomness, Real-World Cryptography is the best modern reference. To implement secure key formats in JavaScript, JavaScript: The Definitive Guide covers Base64, typed arrays, and the Web Crypto API.