Cryptographically secure keys with your prefix, in the format you want, with the entropy math shown. Generated locally with the Web Crypto API — nothing you mint here ever leaves your browser.
Generated with crypto.getRandomValues in your browser — no network request carries these keys, and we never see them. Treat each one as shown-once: store a hash server-side, not the key itself.
A well-designed key has two parts. The prefix (sk_live_, yourapi_) is public information — it tells people and machines what kind of key leaked into a log or a commit, and lets secret scanners match it by pattern. The random part is the actual secret, and its only job is to be unguessable: 128 bits of entropy from a cryptographic source is the bar.
The alphabet is a usability choice, not a security one. Base58 drops the look-alike characters (0/O, I/l) and stays double-click-selectable; base64url is the shortest but its dashes and underscores break double-click selection; hex is the safest bet for systems that mangle case.
Use a cryptographically secure random source — in the browser or Node that is crypto.getRandomValues / crypto.randomBytes — and draw at least 128 bits of entropy. Never use Math.random, timestamps, or anything derived from user data: those are guessable. This page samples every character from crypto.getRandomValues with rejection sampling, so there is no modulo bias.
Think in entropy, not characters: 128 bits is the standard target, and how many characters that takes depends on the alphabet — 32 hex characters, or 22 in base58/base62/base64url. The default here (32 base58 characters) carries about 187 bits, comfortably past the bar.
Yes. A prefix like sk_live_ or yourapi_ costs nothing in security (the secret entropy lives in the random part) and buys a lot: humans and log tooling can identify the key type and environment at a glance, and secret-scanning systems — like the ones GitHub runs on every public commit — can match leaked keys by prefix and alert you before someone abuses them.
A version-4 UUID from a cryptographic generator carries 122 bits of randomness, which is acceptable. But the format wastes 36 characters on 122 bits, some UUID libraries are not cryptographically random, and other UUID versions (v1, v7) embed timestamps. If you control the format, a prefixed random string is strictly better.
Show the full key exactly once at creation, then store only a hash. Because a generated key already has 128+ bits of entropy, a single fast hash like SHA-256 is fine — you don’t need bcrypt-style stretching, which exists for low-entropy passwords. Keep the last 4 characters in plaintext for display (“…k4Jw”), and compare hashes with a constant-time comparison.
The keys are generated entirely in your browser with the Web Crypto API — no network request carries them, we never see or store them, and you can verify that in your browser’s network tab. For the truly paranoid: generate on an offline machine, or use this page’s logic (rejection-sampled crypto.getRandomValues) in your own code.
ReqKey mints keys with your prefix, validates them in under 5ms, and gives every key a credit balance with limits, refills, and per-consumer usage — one API call from your middleware.