Your files never leave your device. All processing happens locally in your browser.
How do I generate a secure API key or token?
Pick a format — a prefixed Stripe/GitHub-style key (sk_live_…, ghp_…), URL-safe base62 alphanumeric, RFC 4648 base64url, lowercase hex, or an RFC 4122 UUID v4 — set the entropy in bytes (16 bytes = 128-bit, 32 bytes = 256-bit), and this tool draws the key from window.crypto.getRandomValues, never Math.random. Optionally append a GitHub-style CRC-32 checksum so typos are detectable. Everything runs locally; nothing is uploaded.
Randomness from window.crypto.getRandomValues (a CSPRNG), never Math.random
Base62 keys use unbiased rejection sampling — no modulo bias
Optional 6-char base62 CRC-32 checksum makes mistyped keys detectable
Batch up to 100 keys, copy each, copy all, or download as .txt / .env — 100% client-side
What is
API Key
An API key is a secret token a client sends to an API to authenticate and authorise its requests. A good key is a long, high-entropy random string drawn from a CSPRNG (so it cannot be guessed), often carrying a human-readable prefix such as sk_live_ or ghp_ that identifies its type and lets secret scanners flag leaks. The random body is what provides security; a prefix and an optional checksum add none. Because it is a bearer credential, an API key should be treated like a password: stored hashed on the server, scoped to least privilege, rotated, and never committed to source control.
No. Every key is generated in your browser with crypto.getRandomValues and is never uploaded, logged or stored.
The tool is 100% client-side. When you generate keys, they are drawn locally from <code>window.crypto.getRandomValues</code> — there is no network request, no upload, no logging, no server and no CDN in the generation path. The keys exist only in your tab’s memory; reload the page and they are gone forever, with no history kept. The only optional network use anywhere on the site is consent-gated ads, which never see your keys. Because the randomness is produced where you are, you never have to trust a remote server not to keep a copy of your secret.
Aim for at least 128 bits of entropy (16 random bytes); 256 bits (32 bytes) is a comfortable default that costs nothing extra.
Security comes from the entropy of the random body, not the visible length. 128 bits (16 random bytes) is a sensible floor for a secret token, and 256 bits (32 bytes) is a generous, common default. In this tool the entropy control is expressed in bytes and a live read-out shows the resulting bit strength: hex and base64url carry 8 bits per input byte, while a base62 body carries about 5.95 bits (log₂62) per character, so the tool sizes the character count to hit your target. A prefix like sk_live_ and a trailing checksum improve usability but add zero entropy.
It is a typo detector, not authentication: a 6-char base62 CRC-32 that lets you catch a mistyped key before a database lookup.
When enabled, the tool appends a GitHub-style 6-character base62 CRC-32 checksum computed over the rest of the key. Your server (or the built-in verifier here) can re-derive it and reject a key that fails the check, catching most single-character typos and transpositions cheaply. But it adds no security: CRC-32 is a public, non-cryptographic algorithm, so anyone can forge a key that passes the checksum. Real validation must still compare the key against a hashed record on your server; the checksum only saves a lookup on obviously-broken input.
Store only a SHA-256 hash of the key, show the raw key to the user once at creation, and scope and rotate keys.
Treat an API key exactly like a password. Never store the plaintext: if your database is breached, plaintext keys hand attackers instant access to every account. Instead store a SHA-256 (or stronger) hash and compare hashes on each request, revealing the raw key to the developer only once, at creation. Scope each key to the minimum permissions it needs, set an expiry where possible, rotate keys on a schedule, and revoke on any suspicion of compromise. Never commit a real key to source control or embed one in client-side code — use a prefix so secret scanners can flag leaks, and keep secrets in a vault or KMS.
Detailed Explanation
📖How It Works
What the API Key Generator Does
The API Key Generator is a 100% client-side tool that produces cryptographically secure API keys and tokens for authenticating requests to an API. The user picks a format — a prefixed Stripe/GitHub-style key (sk_live_…, ghp_…), URL-safe base62 alphanumeric, RFC 4648 base64url, lowercase hex, or an RFC 4122 UUID v4 — sets the entropy in bytes, and reads a live bit-strength read-out. Every key is drawn from window.crypto.getRandomValues, the browser’s cryptographically secure PRNG, and nothing is ever uploaded.
Five formats: prefixed, base62, base64url, hex, UUID v4
Randomness from window.crypto.getRandomValues (a CSPRNG), never Math.random
Entropy set in bytes (16 B = 128-bit, 32 B = 256-bit) with a live bit read-out
Optional secret + publishable pair and a batch of up to 100 keys
Copy each, copy all, or download as .txt / .env — all in the browser
⚙️Methodology
How the Keys Are Produced
Hex and base64url bodies are base-16 and RFC 4648 §5 URL-safe base64 encodings of raw crypto.getRandomValues bytes. Base62 bodies (used by the base62 and prefixed formats) are built character by character with unbiased rejection sampling over crypto.getRandomValues — a random integer is only accepted when it falls within a whole number of buckets of the pool size, so there is no modulo bias. The UUID v4 follows RFC 4122 §4.4, stamping the version and variant bits into 16 random bytes. When enabled, a 6-character base62 CRC-32 (IEEE 802.3) checksum is appended over the rest of the key, GitHub-style, so a mistyped key can be detected before a lookup.
Bodies encode raw CSPRNG bytes (hex / base64url) or unbiased base62 characters
Base62 uses rejection sampling — no modulo bias, every character equally likely
UUID v4 stamps version (0x40) and variant (0x80) bits per RFC 4122
Checksum is a base62 CRC-32 (IEEE 802.3) over the preceding characters
A prefix and checksum add readability, not entropy
📋Use Cases
Choosing a Format and Size
Security comes from the entropy of the random body, not the visible length. 128 bits (16 random bytes) is a sensible floor for a secret token and 256 bits (32 bytes) is a comfortable default that costs nothing extra. Prefixed keys are the modern best practice: a readable prefix such as sk_live_ or ghp_ makes a key self-identifying and lets secret scanners (GitGuardian, TruffleHog) flag leaks in public repositories. Base64url is the usual default when a compact URL-safe token is enough; base62 is the right choice when the alphabet must be purely alphanumeric; a UUID v4 suits an opaque, fixed-shape identifier.
128-bit (16 B) minimum; 256-bit (32 B) a comfortable default
Prefixes (sk_live_, ghp_, xoxb-) make keys self-identifying and scannable
base64url for compact URL-safe tokens; base62 for alphanumeric-only
UUID v4 for an opaque, fixed-shape 122-bit identifier
The randomness here is CSPRNG-quality (crypto.getRandomValues, the same class as openssl rand) and unbiased, but generation is the easy part. A key is only as safe as where it ends up: pasting one into a chat, a commit, a screenshot or an unencrypted note is the real leak. On the server, store a SHA-256 hash of each key rather than the plaintext, so a database breach does not expose every key, and reveal the raw key to the developer only once. The optional CRC-32 checksum is a typo detector, not authentication — it is public and forgeable, so keys must still be validated against a hashed record. Scope and rotate keys, and never commit them to source control.
A key’s safety depends on where it is stored, not the draw
Store a SHA-256 hash server-side, never the plaintext key
CRC-32 checksum detects typos but is public and forgeable
Scope, expire and rotate keys; revoke on suspicion
A publishable key is still a credential, just lower-privilege
🔒Privacy & Security
Private by Design
Everything happens on your device. The keys are generated by the browser’s own CSPRNG and the formatting is pure local JavaScript — there is no network request, no upload, no logging, no server and no CDN in the generation path. Nothing is persisted or added to history; reload the page and the keys are gone. The tool works offline once cached, and the only optional network use anywhere on the site is consent-gated ads, which never see your keys. This matters because an API key is a live secret you would never want to round-trip through a remote server just to create it.
Keys generated locally by the browser CSPRNG — nothing uploaded
No server, no CDN, no logging, no telemetry, no account
Nothing persisted; keys vanish on reload
Works offline once cached; dark-mode and mobile-first
Keeps your secrets entirely on your machine
API key formats and when to use them
Format
Alphabet
URL-safe?
Best for
Prefixed (Stripe/GitHub)
prefix + base62 (+ CRC-32)
Yes
Production keys — self-identifying, scannable, optionally checksummed
Base62 alphanumeric
A–Z a–z 0–9
Yes
Tokens that must be purely alphanumeric; unbiased rejection sampling
Base64URL
A–Z a–z 0–9 - _
Yes
Compact URL-safe tokens (RFC 4648 §5); the usual default
Hex
0–9 a–f
Yes
Simple, unambiguous keys; 2 characters per random byte
UUID v4
8-4-4-4-12 hex
Yes
Opaque fixed-shape identifiers (RFC 4122); 122 random bits
Security depends on the entropy of the random body, not the format or length. Prefixes and checksums add usability, not entropy. Everything runs locally in the browser; nothing is uploaded. As of July 2026.
