0 bits of entropy
Key size
Encoding
Random API keys in URL-safe characters, generated in your browser. No network, no logs, nothing uploaded.
Press Space for a new key, C to copy. Generated with crypto.getRandomValues on your own device — this page loads nothing from the network.
An API key is not a cryptographic key in the sense the other generators here produce one — nothing signs or decrypts with it. It is a long random string your server recognises, so the only property that matters is that nobody can guess it or produce another one your server would accept. 128 bits of randomness already puts it out of reach; 256 is what most services settle on.
The bytes come from crypto.getRandomValues, the browser's cryptographically secure random number generator, and are written out as Base64URL or hexadecimal. Both alphabets pass through a URL, an HTTP header, an environment variable and a shell command without escaping — which is why plain Base64, with its +, / and = characters, is not offered here. No timestamp, no counter, and no Math.random anywhere in the path.
Everything happens on your own device. The page makes no network requests after it loads, so this key has never existed anywhere else and never travels. Reload and it is gone, which also means you should paste it into your key store before you close the tab.
128 bits of randomness — 22 Base64URL characters — is already beyond brute force, and nobody is going to find such a key by guessing through your rate limiter. 256 bits is the common default, largely because it costs nothing and keeps the question from coming up in review. Length beyond that buys no security at all; it only makes the key harder to paste and likelier to be truncated by some log line or database column along the way.
You can, but it is a weaker choice than it looks. A random UUIDv4 carries 122 bits rather than 128, because six of them are fixed version and variant markers — still enough, but only when a CSPRNG sits behind it, and plenty of implementations quietly use the ordinary random number generator instead. UUIDv1 and v7 embed a timestamp and are partly predictable by design. A UUID also announces itself as an identifier, which invites everything downstream to treat it as one and log it.
Yes, if you are issuing keys rather than consuming them. Something like sk_live_ or myapp_ makes a leaked key identifiable at a glance and, more usefully, gives GitHub and GitLab secret scanning a pattern to match, so a key committed by accident gets reported instead of sitting there. It also lets you route or reject on the prefix before touching the database. Prepend it to the value from this page: a prefix is not secret and adds no entropy, so it replaces none of the random part.
Hashed, exactly as you would a password — a key that can be read out of your database is a breach waiting to be exported. Unlike a password, though, a plain SHA-256 is enough and a slow hash such as bcrypt is not needed: the key is already 128 bits of uniform randomness, so there is no dictionary to run against it and no reason to pay that cost on every request. Keep a prefix or the last four characters in the clear so the key can be identified in a list, and show the full value exactly once, at creation.
An API key is opaque: it means nothing except to the system that issued it, which has to look it up to check it. A JWT is the opposite — it carries its claims and its expiry inside itself, signed, so a service can verify it without any lookup. Tokens in the OAuth sense sit nearer the JWT end: short-lived, scoped, and issued after some other authentication. Use a key when a machine needs long-lived access it can keep in a config file, and a token when the access ought to expire on its own.
The same bytes either way; what differs is length and where the string survives unescaped. Base64URL is shorter — 256 bits is 43 characters against hex's 64 — and its alphabet is A-Z, a-z, 0-9, hyphen and underscore, all of which pass through URLs, headers and shells untouched. Hex is longer but easier to read aloud, dictate and compare by eye, and it never trips over anything that mishandles case. Ordinary Base64 is the one to avoid: + and / need escaping in a URL, and = padding is routinely stripped in transit.
Avoid it. Query strings are written into server access logs, proxy logs and browser history, and they leak through the Referer header to whatever the page links to next — none of which is under your control once the request has left. Send the key in an Authorization header instead, as Authorization: Bearer followed by the key, which no ordinary log records by default. The URL-safe alphabet here exists for the occasional path segment or webhook callback, not to make the query string a reasonable place for a secret.
With far less ceremony than a cryptographic key: rotating an API key re-encrypts nothing, so the entire cost is in coordinating the clients. Let each account hold two active keys at once and rotation becomes create, deploy, revoke, with no window in which the integration is down. On a schedule, once or twice a year is plenty for most systems. What matters much more is that revocation is immediate and self-service, because the rotation that counts is the unplanned one.
Only if the page cannot transmit it, and that is checkable rather than something to take on faith. Open developer tools, sit on the Network tab, and generate as many keys as you like: nothing is requested after the page loads. There is no server behind this to receive anything, and no analytics or third-party script to leak it. The key lives in one tab's memory until you paste it somewhere, and is gone on reload.