API Key & Secret Generator

About the API Key & Secret Generator

Create API keys, access tokens, webhook signing secrets and framework secrets that cannot be guessed. The random part comes from your browser's cryptographically secure generator (crypto.getRandomValues), choose a strength from 128 to 512 bits and an encoding: Base62 (letters and digits), hex, Base64url, Base32 or Crockford Base32. The entropy shown is exact, and nothing is stored or sent anywhere.

Add a prefix such as myapp_live_ so that you, your logs and secret scanners can tell what a leaked key belongs to, and an optional 6-character checksum in the style of GitHub's token format, so typos and look-alike strings can be rejected without a database lookup. Presets reproduce the generators of Django (SECRET_KEY), Laravel (APP_KEY), Rails and Phoenix (secret_key_base), Flask, Auth.js/NextAuth (AUTH_SECRET) and HS256/HS384/HS512 JWT secrets, with the line to paste into your configuration.

Common uses

• Issuing API keys to your customers or internal services, with a prefix per environment (live/test).
• Webhook signing secrets and HMAC keys for request signatures.
• SECRET_KEY, APP_KEY, secret_key_base and AUTH_SECRET values for a new deployment or after a leak.
• HS256/HS384/HS512 secrets for signing JSON Web Tokens.
• Batches of test tokens for development and staging environments.

How strong should a key be?

A random key with 128 bits of entropy has 2¹²⁸ possible values: far beyond what anyone can try by brute force. Use 256 bits for anything that signs or encrypts data — RFC 7518 §3.2 requires keys of at least 256 bits for HS256 (384 for HS384, 512 for HS512). The strength you choose is the real entropy: hex, Base64url and Base32 keys encode exactly that many random bytes, and Base62 keys are rounded up to whole characters (43 characters ≈ 256.0 bits).

What matters as much as length is the source of the randomness. RFC 4086 warns that "the use of pseudo-random processes to generate secret quantities can result in pseudo-security": keys must come from a cryptographic generator, never from Math.random(), timestamps or hashes of predictable data. Each character here is picked with rejection sampling so that every symbol is exactly equally likely.

Prefixes and checksums

GitHub's 2021 token format (Behind GitHub's new authentication token formats) starts every token with an identifiable prefix such as ghp_, uses an underscore because it is not a Base64 character and keeps the whole token selectable with a double-click, and ends with a 32-bit CRC checksum in 6 Base62 characters, so leaked tokens can be found with very few false positives. The OWASP Secrets Management Cheat Sheet makes the same point: secrets with consistent formats are easier to detect.

The checksum here works the same way but is fully specified: it is the CRC-32 (IEEE 802.3, as in zlib) of the UTF-8 bytes of everything before it — the prefix and the random part — written as 6 Base62 digits (0–9, A–Z, a–z) with leading zeros. It catches typos; it adds no secrecy, because anyone can compute it. GitHub has not published which part of its own tokens its CRC covers, so these keys are GitHub-style, not GitHub tokens. Keep prefixes generic (service and environment) — never put customer names or other information in them.

Framework presets

Each preset produces exactly what the framework's own command produces, checked against its source code or documentation on 2026-10-03:

• Django SECRET_KEY: 50 characters from a–z 0–9 !@#$%^&*(-_=+) (282 bits), like get_random_secret_key(); it passes the security.W009 deployment check (at least 50 characters, 5 unique, no "django-insecure-" prefix), and the settings.py line reads it from the environment instead of holding it.
• Laravel APP_KEY: "base64:" and 32 random bytes in Base64, like php artisan key:generate for AES-256-CBC.
• Rails secret_key_base: 128 hex characters, like bin/rails secret.
• Auth.js / NextAuth AUTH_SECRET: 32 random bytes in Base64, like npm exec auth secret.
• Flask SECRET_KEY: 64 hex characters, like secrets.token_hex() in Flask's docs; the .env line uses the FLASK_ prefix that app.config.from_prefixed_env() reads.
• Phoenix secret_key_base: 64 Base64 characters, like mix phx.gen.secret.
• JWT HS256 / HS384 / HS512: 32, 48 or 64 random bytes in Base64url.

Storing, sharing and rotating keys

• Keep secrets out of source code and Docker images; load them from a secrets manager or your platform's encrypted settings. OWASP notes that environment variables are visible to every process and can end up in logs and dumps.
• On the server, store API keys you issue as a hash (for example SHA-256) rather than in plain text, show the full key to its owner once, and compare in constant time. Because these keys are long and random, a fast hash is enough — unlike passwords, which need bcrypt or Argon2.
• Rotate secrets regularly and immediately after a suspected leak, and give keys an expiry date where your system supports it.

Limitations

• Keys are not saved anywhere. Copy them before you leave or reload the page.
• Copied keys stay on your clipboard (and in any clipboard history) until you copy something else.
• Base62 has no standard byte encoding, so a Base62 key cannot be decoded back to key bytes. Use hex or Base64url when a system expects raw key bytes, such as an AES key.
• The checksum detects mistakes, not forgeries. Validate keys on your server against what you stored.

Privacy

Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.