Token & API Key Generator
Cryptographically secure tokens using the Web Crypto API. UUID, hex, Base64 bearer tokens, or prefixed API keys.
A 128-bit RFC 4122 v4 identifier, 122 bits of it random. The default choice for database primary keys, request IDs and correlation tokens.
122 bits of entropy · generated in your browser, never sent to a server
Why not Math.random()?
Math.random() is a pseudorandom number generator — its output is predictable and unsuitable for security tokens. This tool uses crypto.getRandomValues(), the same API that powers TLS and SSH key generation.
Token types explained
UUID v4 is the standard for database IDs and correlation tokens. Hex strings work well for session tokens and nonces. Base64 is compact for API tokens. API keys with prefixes (like sk_ or vlt_) make it easy to identify and rotate leaked credentials.
How long should a token be?
128 bits of entropy is the floor for anything guarding access, and it is what NIST SP 800-63B expects from a randomly generated secret. That is 32 hex characters, 22 Base64 characters, or one UUID v4. Going beyond 256 bits buys nothing against brute force - it only costs you log volume and header size. Length matters more than alphabet: a 32-character hex token and a 22-character Base64 token are equally hard to guess.
Bearer tokens, access tokens and API keys
These names describe how a credential is used, not how it is generated. A bearer token grants access simply by being presented, which is why the HTTP Authorization header carries it verbatim. An access token is a bearer token with a short lifetime, usually issued by an OAuth flow. An API key is a long-lived bearer token issued to a service rather than a person. At generation time all three are the same thing: an opaque, high-entropy random string. Use hex or Base64 for the first two, and the API key mode when you want a scannable prefix.
Why prefix your API keys?
GitHub, Stripe, OpenAI and Slack all prefix their keys (ghp_, sk_live_, xoxb_) for one reason: secret scanners can then recognise a leaked key from the string alone, with no surrounding context. Push a prefixed key to a public repository and the issuer can revoke it within minutes. A bare 32-character hex string looks like a commit hash, so nothing catches it. Prefixes also make environments obvious at a glance, which is the cheapest defence against pasting a production key into a staging config.
Frequently asked questions
Are these tokens actually random?
Yes. Every token comes from crypto.getRandomValues(), the browser's cryptographically secure random number generator, seeded by the operating system's entropy pool. It is the same primitive that generates TLS session keys. Math.random(), which many online generators still use, is a predictable pseudorandom generator and must never produce a security token.
Is my token sent to your server?
No. Generation happens entirely in your browser using the Web Crypto API. Open your network tab and generate a token: no request is made. Nothing is logged, stored or transmitted. If you then choose to share the token, it is encrypted in your browser before anything leaves the page.
What length should I use for an API key?
128 bits of entropy, which is exactly what this tool's API key mode produces: your prefix plus 32 hexadecimal characters. That is unguessable in practice and matches what Stripe, GitHub and AWS issue. Go higher only if a specific compliance requirement asks you to.
What is the difference between a UUID v4 and a random hex token?
A UUID v4 is a random token with a fixed shape: 36 characters, four hyphens, and six bits reserved for the version and variant, leaving 122 random bits. Use it when something else expects that shape, such as a database uuid column. Use plain hex or Base64 when you simply need a secret and the format is yours to choose - it is shorter for the same strength.
Can I generate several tokens at once?
Yes. Set the count to 5, 10 or 25 and each token is generated independently. Copy all copies them one per line, the format most seed scripts, .env files and password managers accept for bulk import.
How do I send a token to a colleague safely?
Not in Slack, email or a ticket - those keep a copy indefinitely, so anyone who later gains access to the channel gains access to the credential. Use Share securely to put the token behind an encrypted, self-destructing link: it is encrypted in your browser, the key travels in the URL fragment and is never sent to our server, and the secret is destroyed once it is read or when it expires.
Need to share a token securely?
Don't paste tokens in Slack or email. Send them via an encrypted, self-destructing link that only the recipient can open.