Generate API keys, session tokens and other secrets with a stated entropy budget in bytes. Output as hex, Base64URL, Base58 or alphanumeric, with an optional prefix such as sk_live_. Sized in bytes rather than characters so the security claim is unambiguous.
Settings
Recent results
Generated locally in your browser β your settings and results never leave this page.
Entropy is the only number that matters
A token is a secret whose only job is to be unguessable. Everything else about it β how long the string looks, which characters it contains, whether it has a friendly prefix β is presentation. The security comes from the number of random bits behind it, which is why this tool asks for bytes and reports bits rather than letting you pick a character count and hope.
The conversion is fixed: one byte is eight bits. Sixteen bytes is 128 bits, which is the strength of a standard AES key and far beyond any feasible brute-force search. Thirty-two bytes is 256 bits. Once you are past 128 bits the token has stopped being the weakest link in any realistic system, and effort is better spent on rotation, scoping and revocation.
Why format and strength are separate questions
The same 32 random bytes can be shown as 64 hex characters, about 43 Base64URL characters, or about 44 Base58 characters. All three carry identical strength. Choosing between them is a question about where the token will travel, not how secure it is.
Hex is the safest default because nothing anywhere treats its characters specially. Base64URL is shorter and survives being placed in a URL path or query string without escaping, which matters for links in emails and webhooks. Base58 drops the characters that are easy to confuse β zero and capital O, capital I and lowercase l β which is worth having if a human might ever read the value off a screen and type it somewhere else.
Prefixes make leaks findable
A bare random string tells you nothing about itself. A prefixed one announces what it is: which service issued it, and whether it is a live or a test credential. That has two practical benefits. Someone reviewing a pull request can recognise a committed secret at a glance, and automated secret scanners can search for the prefix pattern rather than trying to identify high-entropy strings by shape.
The prefix contributes no entropy and is not meant to. It sits alongside the random portion, which is why the tool applies it without reducing the number of random bytes you asked for.
Treat tokens like passwords, because they are
A token is a credential that grants access without a second factor, which in most systems makes it more dangerous than a password rather than less. The handling should reflect that. Store a hash rather than the value, so that reading your database does not hand an attacker working keys. Display the full token exactly once. Attach an expiry date and make revocation a single, fast operation.
Scope matters as much as strength. A token that can only read one resource is a far smaller problem when it leaks than one that can do anything the account can do. No number of random bits helps if the leaked key has full administrative access.
Where to generate production secrets
This tool is well suited to development, testing, seeding fixtures and generating values you will paste into a configuration you control. For a production secret that guards real customer data, generating it on the machine that will use it is better practice β it never crosses a screen, a clipboard or a browser process. Most platforms provide a command-line equivalent, and the underlying randomness is the same.
Privacy
Tokens are generated in your browser and never transmitted, stored, logged or placed in the page URL. The tool has no share link, deliberately, because sharing a link that reconstructed a secret would defeat the point.
How to use the Secure Token Generator
- Decide how much entropy the token needs, in bytes. Sixteen bytes (128 bits) is the usual minimum for a session or API token; 32 bytes is a comfortable default.
- Pick an output format β hex is universally safe, Base64URL is shorter and fits in a URL, Base58 avoids look-alike characters.
- Add a prefix such as sk_live_ if your system uses one to identify the key type.
- Generate and copy. Store the token where it belongs and do not paste it anywhere else.
Frequently asked questions
Why is this sized in bytes rather than characters?
Because bytes map directly to security and characters do not. Thirty-two hex characters and thirty-two Base64 characters carry very different amounts of entropy β 128 bits against roughly 192. Asking for bytes means the strength you requested is the strength you get, whatever format you then choose to display it in.
How many bytes should I use?
Sixteen bytes gives 128 bits, which is the usual floor for a value that protects access and is the same strength as a standard AES key. Thirty-two bytes gives 256 bits and costs nothing extra in practice. Going beyond 32 bytes rarely buys anything real, because at that point the token is no longer the weakest part of the system.
What is the difference between the output formats?
They encode the same random bytes differently. Hex uses sixteen characters and is unambiguous everywhere. Base64URL uses sixty-four characters including hyphen and underscore, so it is shorter and safe in a URL or filename. Base58 removes the characters that look alike, which helps when a token might be transcribed by hand. Alphanumeric is the plainest option for systems that reject punctuation.
Is it safe to generate a production API key here?
The generation itself is sound β it uses your browser's cryptographic random source and the value never leaves the page. The risk is everything around it: the token appears on your screen, may land in your clipboard, and could be captured by other software on the machine. For production secrets, generating them on the server that will use them is safer, and most platforms provide a command for exactly that.
What does the prefix do?
It is prepended to the token without consuming any of the random bytes, so a 32-byte token with a prefix still carries 256 bits. Prefixes are a convention that makes keys self-describing: it is immediately obvious which system a key belongs to and whether it is a live or test credential, which makes accidental leaks easier to spot and revoke.
Should I use seeded mode for tokens?
No, other than for demonstrations. Seeded mode is reproducible by design, so anyone with the seed can regenerate the token. The tool warns you when seeded mode is active for this reason. Leave it on the cryptographic setting for anything that grants real access.
How should tokens be stored?
Store a hash of the token rather than the token itself, in the same way you would treat a password, so a database leak does not hand over working credentials. Show the full value to the user once at creation and never again. Give every token an expiry and a way to revoke it β being able to invalidate a leaked key quickly matters more than its length.
