API Key Generator

Long enough that guessing is pointless, which happens well before it becomes inconvenient. At 5.95 bits per alphanumeric character, a 32-character key carries about 191 bits and a 40-character key about 238. Both are far past the point where brute force is a realistic threat, so choose 32 as a floor and go longer for production credentials.

Because they cost more than they add. Moving from 62 alphanumerics to roughly 90 printable characters buys about half a bit per character, which one extra character replaces entirely, while symbols reliably break shell quoting, URL parameters, YAML files, and .env parsing. Machine credentials should be boring to transport.

Yes. A prefix such as acme_live_ or acme_test_ makes the credential self-identifying, which is what lets automated secret scanners spot it in a public repository, lets log scrubbers redact it, and lets you tell a production key from a sandbox key at a glance. It costs no entropy because it was never secret.

Store a hash, not the key. Show the value once at creation, persist only its hash, and compare hashes at authentication time. Envless does exactly this with its own keys, which is why a key can be rotated but never revealed a second time. A database dump then yields nothing usable.

Not in the repository, and not in a plaintext .env file copied between machines. Keep third-party keys in a secrets manager that encrypts them and hands them to your process at runtime. Envless encrypts values client-side before upload and injects them into any command, so the key never touches disk in plaintext.

No. It is produced in your browser with crypto.getRandomValues() and never transmitted, logged, or stored. There is no network request at any point, which is the only arrangement under which a generated credential is trustworthy.

On a schedule you can actually keep, and immediately on any suspicion of exposure: a key pasted in a chat, committed to a branch, or held by someone who has left the team. Rotation only works if it is cheap, so favour a setup where the key lives in one place and every consumer reads it from there rather than holding its own copy.

An API key is an opaque random string that means nothing on its own, because the server looks it up to learn who is calling. A JWT is a signed, self-describing token carrying claims that any holder of the key can verify without a lookup. Use an API key for long-lived service credentials, and a JWT for short-lived sessions where you want the token to carry its own context.