πŸ”‘

API Key Generator

Generate secure, cryptographically random API keys for authentication and authorization. Create custom API keys with various formats including hex, base64, and prefixed keys.

Security
Loading tool...

How to Use API Key Generator

How to Use API Key Generator

Getting Started

API keys are secret tokens used to authenticate and authorize access to APIs and services. This tool generates cryptographically secure random keys using your browser's crypto.getRandomValues() function.

Basic Key Generation

  1. Select Key Format: Choose the format that matches your needs

    • Hexadecimal (32 chars): Standard hex format (128 bits)
    • Hexadecimal (64 chars): Long hex format (256 bits) ⭐
    • Base64 (32 chars): URL-safe Base64 (192 bits)
    • Base64 (43 chars): Standard token (256 bits) ⭐
    • Alphanumeric (32 chars): Letters and numbers (190 bits)
    • Prefixed Key (sk_live): Stripe-style prefixed (128+ bits)
  2. Key Generated Automatically: New key appears instantly

    • Key generated on page load
    • Updates when format changes
    • Uses cryptographically secure randomness
    • Completely client-side (browser only)
  3. Copy API Key: Save your generated key

    • Click copy icon to copy to clipboard
    • Visual confirmation when copied
    • Paste into your application
    • Store securely (never in code!)
  4. Generate New Key: Create another key

    • Click refresh icon or "Generate New" button
    • New random key generated instantly
    • Each key is completely unique
    • No history or logging

Features

Multiple Key Formats

Hexadecimal (32 characters):

  • Format: Lowercase hex (0-9, a-f)
  • Entropy: 128 bits
  • Example: a3f5b2c8d1e4f6a7b9c0d2e3f4a5b6c7
  • Use for: Standard APIs, general authentication
  • Strength: Good - suitable for most applications

Hexadecimal (64 characters):

  • Format: Lowercase hex (0-9, a-f)
  • Entropy: 256 bits
  • Example: a3f5b2c8...f2a3 (64 chars)
  • Use for: High-security applications, webhooks ⭐
  • Strength: Very Strong - maximum security

Base64 (32 characters):

  • Format: URL-safe Base64 (A-Z, a-z, 0-9, -, _)
  • Entropy: 192 bits
  • Example: A9fK2mP5xL8qY3tW6nR4vB7hG1jD0sF
  • Use for: Compact keys, HTTP headers
  • Strength: Strong - good balance

Base64 (43 characters):

  • Format: URL-safe Base64
  • Entropy: 256 bits
  • Example: A9fK2mP5xL8qY3tW6nR4vB7hG1jD0sFpE4cN9vM
  • Use for: Production APIs, mobile apps ⭐
  • Strength: Very Strong - industry standard

Alphanumeric (32 characters):

  • Format: Letters and numbers (A-Z, a-z, 0-9)
  • Entropy: 190 bits
  • Example: K9mP2xL5nQ8wT3hR7vB1dF6cN0sM4jG
  • Use for: Systems that don't support special chars
  • Strength: Strong - widely compatible

Prefixed Key (sk_live format):

  • Format: Prefix + hex key
  • Entropy: 128+ bits
  • Example: sk_live_a3f5b2c8d1e4f6a7b9c0d2e3
  • Use for: SaaS platforms, Stripe-style keys
  • Strength: Good - easy to identify and manage

Real-Time Entropy Analysis

Strength Meter:

  • Visual progress bar shows key strength
  • Color-coded indicator (red to green)
  • Updates based on selected format
  • Shows entropy in bits

Entropy Levels:

  • Very Weak (< 80 bits): Not for production
  • Weak (80-127 bits): Minimum for non-critical
  • Good (128-191 bits): Standard applications
  • Strong (192-255 bits): Sensitive data
  • Very Strong (256+ bits): Maximum security ⭐

Security Metrics:

  • Entropy displayed in bits
  • Total combinations shown as 2^bits
  • Strength level label and description
  • Key length in characters

Automatic Generation

On Page Load:

  • Key generated immediately when tool loads
  • Uses default format (Base64 43 chars)
  • Ready to copy instantly
  • No manual action needed

On Format Change:

  • New key generated when format changes
  • Automatically updates to match new format
  • Smooth transition
  • Instant feedback

Copy & Regenerate

Copy to Clipboard:

  • One-click copy with icon button
  • Visual checkmark confirmation
  • Confirmation disappears after 2 seconds
  • Works on all modern browsers

Regenerate Key:

  • Refresh icon for quick regeneration
  • Large "Generate New" button
  • Creates completely new random key
  • Previous key is replaced (not saved)

Privacy & Security

Cryptographic Randomness:

  • Uses crypto.getRandomValues() Web Crypto API
  • Cryptographically secure random number generation
  • Not Math.random() (which is predictable)
  • Industry-standard randomness source

Client-Side Only:

  • All generation happens in your browser
  • No network requests made
  • Keys never sent to any server
  • Complete privacy guaranteed

No Storage:

  • Keys not saved anywhere
  • No browser storage used
  • No logging or history
  • Cleared when page refreshed

Understanding API Keys

What are API Keys?

Definition: API keys are secret tokens that authenticate and authorize access to APIs (Application Programming Interfaces).

Purpose:

  • Authentication: Identify who is making the request
  • Authorization: Control what actions are allowed
  • Rate Limiting: Track usage per key
  • Analytics: Monitor API usage patterns

How They Work:

  1. Server generates API key for client
  2. Client stores key securely
  3. Client includes key in API requests (header or body)
  4. Server validates key before processing request
  5. Server grants or denies access based on key

API Keys vs Other Auth Methods

API Keys vs Passwords:

  • API Keys: For programmatic access (scripts, apps)
  • Passwords: For human users (login forms)
  • API Keys: Can be easily revoked and rotated
  • Passwords: Tied to user accounts
  • API Keys: Used in code and automation
  • Passwords: Typed by humans

API Keys vs OAuth Tokens:

  • API Keys: Simple, long-lived, static
  • OAuth Tokens: Complex, short-lived, dynamic
  • API Keys: Direct access with key
  • OAuth: Delegated access with permissions
  • API Keys: Easier to implement
  • OAuth: Better for third-party access

API Keys vs JWT:

  • API Keys: Opaque string, looked up server-side
  • JWT: Contains encoded data, can be verified without DB
  • API Keys: Easier to revoke (just delete from DB)
  • JWT: Stateless, no DB lookup needed
  • API Keys: Simpler but requires database
  • JWT: More complex but scalable

Security Considerations

Entropy Requirements:

  • Minimum: 128 bits (32 hex or 22 base64 chars)
  • Recommended: 256 bits (64 hex or 43 base64 chars)
  • Why: Prevents brute force attacks
  • Math: 2^128 = 340 undecillion combinations

Key Length Matters:

128 bits = 3.4 Γ— 10^38 combinations (good)
256 bits = 1.1 Γ— 10^77 combinations (excellent)

Brute force at 1 billion attempts/second:
128 bits: 5.4 Γ— 10^21 years to crack
256 bits: 3.7 Γ— 10^60 years to crack

Random Generation:

  • Use crypto.getRandomValues() (this tool)
  • Never use Math.random() (predictable)
  • Never use timestamps (predictable)
  • Never use incrementing numbers (guessable)

Common Use Cases

REST API Authentication

Implementation:

Client request:
GET /api/users
Authorization: Bearer A9fK2mP5xL8qY3tW6nR4vB7hG1jD0sFpE4cN9vM

Server validation:
1. Extract API key from Authorization header
2. Look up key in database
3. Verify key is active (not revoked)
4. Check key permissions
5. Process request or return 401 Unauthorized

Best Practices:

  • Send in Authorization header (not URL)
  • Use Bearer token scheme
  • Implement rate limiting per key
  • Log key usage for security monitoring

Webhook Secrets

Purpose: Generate secret keys for HMAC signature verification of webhooks.

Usage:

1. Generate 64-char hex key (256 bits)
2. Share key with webhook provider (GitHub, Stripe)
3. Provider signs webhook payload with HMAC-SHA256
4. Your server verifies signature before processing
5. Prevents spoofed webhooks

Benefits:

  • Verify webhook authenticity
  • Prevent unauthorized webhooks
  • Detect tampered payloads
  • Secure callback endpoints

SaaS Platform Keys

Stripe-Style Prefixed Keys:

sk_test_a3f5b2c8d1e4f6a7  (secret key, test mode)
sk_live_b4c6d3e9f1a2b5c8  (secret key, live mode)
pk_test_c5d7e4f0a2b3c6d9  (publishable key, test)
pk_live_d6e8f5a1b3c4d7e0  (publishable key, live)

Prefix Benefits:

  • Easy to identify key type (secret vs publishable)
  • Easy to identify environment (test vs live)
  • Prevents accidental use of wrong key
  • Better error messages
  • Audit trail and logging

Implementation:

  • sk_ = secret key (server-side only)
  • pk_ = publishable key (can be public)
  • test = test environment
  • live = production environment

Internal Microservices

Service-to-Service Auth:

Service A β†’ Service B
Header: X-API-Key: K9mP2xL5nQ8wT3hR7vB1dF6cN0sM4jG

Benefits:
- No user context needed
- Simple authentication
- Easy to rotate
- Per-service keys for isolation

Use Cases:

  • Backend service communication
  • Database access tokens
  • Cache authentication
  • Message queue credentials

IoT Device Authentication

Device Provisioning:

1. Generate unique API key per device
2. Flash key to device during manufacturing
3. Device uses key for all API requests
4. Server tracks device by key
5. Can revoke specific device keys

Considerations:

  • One key per device (for individual revocation)
  • Keys stored in secure element if possible
  • Rotate keys periodically
  • Monitor for unusual usage patterns

Mobile App Authentication

App-Specific Keys:

iOS app: One API key for all iOS users
Android app: Different key for Android users

Benefits:
- Track usage per platform
- Revoke all iOS or Android access separately
- Platform-specific rate limits
- Analytics per platform

Security:

  • Keys embedded in app (can be extracted)
  • Use additional user authentication (OAuth)
  • Rotate keys regularly
  • Monitor for key extraction/abuse

Security Best Practices

Key Generation

Use Cryptographic Randomness:

// Good: Cryptographically secure (this tool uses this)
const array = new Uint8Array(32)
crypto.getRandomValues(array)

// Bad: NOT cryptographically secure
const bad = Math.random().toString(36).substring(2)

Adequate Length:

  • Minimum: 128 bits (32 hex chars)
  • Recommended: 256 bits (64 hex or 43 base64 chars)
  • Critical systems: 256+ bits always

Key Storage

Server-Side Storage:

βœ“ DO:
- Store hash of key in database (bcrypt, scrypt)
- Use environment variables for service keys
- Use secrets manager (AWS Secrets Manager, Vault)
- Encrypt at rest in database
- Use separate keys DB with strict access

βœ— DON'T:
- Store keys in plain text
- Commit keys to Git
- Put keys in config files in repo
- Store in cookies or localStorage
- Log full keys (log only prefix/suffix)

Client-Side Storage:

βœ“ DO:
- Store in secure credential store (OS keychain)
- Use environment variables for scripts
- Encrypted configuration files
- Password manager for personal use

βœ— DON'T:
- Hardcode in source code
- Store in plain text files
- Include in client-side JavaScript
- Put in URLs or GET parameters

Key Transmission

HTTPS Only:

βœ“ DO:
Authorization: Bearer <api-key>
Content-Type: application/json

βœ— DON'T:
GET /api/data?api_key=<key>  (in URL - bad!)

Best Practices:

  • Always use HTTPS (even development)
  • Send in Authorization header
  • Never in URL query parameters
  • Can use POST body for sensitive ops
  • Never in GET requests

Key Rotation

Rotation Schedule:

Critical systems: Quarterly
Standard applications: Annually
Non-production: As needed

Process:
1. Generate new API key
2. Deploy new key alongside old key
3. Update clients to use new key
4. Monitor for old key usage
5. Revoke old key after migration complete

Support Multiple Active Keys:

  • Accept both old and new during rotation
  • Gradual client migration
  • No downtime
  • Rollback capability if issues

Key Revocation

Immediate Revocation:

When to revoke immediately:
- Key compromised or leaked
- Employee with access left company
- Security breach detected
- Key found in public repository
- Suspicious usage patterns detected

How to revoke:
1. Mark key as revoked in database
2. Clear any caches
3. Return 401 Unauthorized for revoked keys
4. Log revocation event
5. Alert security team

Revocation Checklist:

  • Database flag or deletion
  • Cache invalidation
  • Audit log entry
  • Security team notification
  • Generate replacement key
  • Update documentation

Monitoring & Logging

What to Monitor:

βœ“ Log these:
- API key usage (timestamp, endpoint, IP)
- Failed authentication attempts
- Unusual usage patterns (rate spikes)
- New IP addresses for existing keys
- Revoked key usage attempts

βœ— Never log these:
- Full API key value
- Sensitive request/response data
- User passwords or PII

Security Alerts:

  • Multiple failed auth attempts
  • Revoked key usage
  • Unusual geographic locations
  • Rate limit exceeded
  • New device/IP for existing key

Troubleshooting

Key Not Working

Common Issues:

  1. Wrong Header Format

    Correct: Authorization: Bearer <key>
    Wrong: Authorization: <key>
    Wrong: X-API-Key <key> (missing colon)
    
  2. Extra Whitespace

    • Trim whitespace before/after key
    • No line breaks in key
    • Check for hidden characters
  3. Wrong Environment

    • Using test key in production
    • Using live key in test
    • Check key prefix if applicable
  4. Key Revoked

    • Check key status in database
    • Verify not expired
    • Generate new key if needed
  5. HTTPS Required

    • Some APIs reject HTTP requests
    • Always use HTTPS in production
    • Check server configuration

Key Generation Issues

Not Random Enough:

Problem: Using Math.random()
Solution: Use crypto.getRandomValues() (this tool)

Problem: Predictable patterns
Solution: Use cryptographic RNG only

Problem: Too short
Solution: Use 128+ bits (32+ hex chars)

Advanced Topics

Key Derivation

Deriving Multiple Keys:

Use case: One master key β†’ multiple derived keys

Method: HKDF (HMAC-based Key Derivation Function)
1. Start with master key
2. Derive read key: HKDF(master, "read")
3. Derive write key: HKDF(master, "write")
4. Derive admin key: HKDF(master, "admin")

Benefits:
- One key to manage
- Multiple scoped keys
- Rotate master to rotate all

Rate Limiting

Per-Key Rate Limits:

Implementation:
1. Track requests per API key
2. Set limit (e.g., 1000 req/hour)
3. Return 429 Too Many Requests when exceeded
4. Include rate limit headers

Headers:
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 247
X-RateLimit-Reset: 1609459200

Key Scoping

Permission Levels:

read_only: sk_live_1a2b3c (GET only)
read_write: sk_live_4d5e6f (GET, POST, PUT)
admin: sk_live_7g8h9i (all operations)

Store permissions with key in database
Check permissions before processing request

Quick Reference

Recommended Key Formats

Use CaseFormatLengthEntropy
REST APIBase6443 chars256 bits ⭐
WebhooksHex64 chars256 bits ⭐
SaaS KeysPrefixed32+ chars128+ bits
IoT DevicesHex32 chars128 bits
Internal ServicesBase6432 chars192 bits
Mobile AppsBase6443 chars256 bits ⭐

Security Checklist

βœ“ Use crypto.getRandomValues() for generation βœ“ Minimum 128 bits entropy (256 bits for production) βœ“ Store keys in environment variables or secrets manager βœ“ Transmit only over HTTPS βœ“ Send in Authorization header, not URL βœ“ Hash keys before storing in database βœ“ Implement rate limiting per key βœ“ Rotate keys regularly (quarterly/annually) βœ“ Support key revocation βœ“ Monitor and log key usage βœ“ Never commit keys to version control

Common Headers

Sending API Key:

Authorization: Bearer <api-key>
X-API-Key: <api-key>

Response Headers:

X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 247
X-RateLimit-Reset: 1609459200

Frequently Asked Questions

Related Utility Tools

Share Your Feedback

Help us improve this tool by sharing your experience

We will only use this to follow up on your feedback