Token generator

What this tool does

Set the character sets you want, drag the length to anywhere between 3 and 512, and press Generate. You get a random string built from the operating system random source, ready to paste into an API client, an environment file, a database seed or a password manager. Generate again and the new one appears above the previous, so you can produce a handful at once — a token, a database password and a signing key — without losing the earlier ones while you paste them.

Upper case, lower case and numbers are on by default and symbols are off, which is the combination that works in the widest range of places. The default length of 64 is deliberately far past what most systems require: for anything a machine reads rather than a person types, extra characters cost nothing and remove the question of whether the token is long enough.

Where there is room, one character from each switched-on set is guaranteed to appear. That is not for strength — it barely moves the number — but for the validators that insist on at least one digit and reject an otherwise fine token that happens to have none.

Where the randomness comes from

Every character here comes from crypto.getRandomValues, the browser interface to the operating system cryptographic random source — the same generator behind the keys your machine uses for TLS. It is not the same as Math.random, which is a fast pseudo-random sequence with no security claim attached to it whatsoever, is seeded predictably in some engines, and has been the quiet flaw behind more than one leaked token generator.

There is a second detail that separates a careful generator from a careless one. Reducing a random byte to a position in the character set with a plain remainder — byte % 62 — is subtly biased, because 256 does not divide evenly by 62: the first few characters of the set come up slightly more often than the rest. This page draws a byte, throws it away if it falls in the uneven tail of the range, and draws again. That is called rejection sampling, it costs a few extra bytes and it makes every character exactly as likely as every other.

The result is a token whose only strength claim rests on the length and the character set — no hidden pattern, no timestamp, no counter, nothing derived from what you were doing on the page.

Nothing leaves your browser

The token is created on your machine and stays there. Nothing you generate becomes a network request: there is no upload, no cookie, no local storage and no log of what appeared on screen. Refreshing the page clears the stack, and closing the tab disposes of it.

For a generator, that property is not a nicety — it is the whole thing. A token produced on somebody else's server has been known to somebody else, and no promise about not keeping it can be verified from the outside. A secret that has travelled over a network to reach you is a secret with a second copy somewhere, and the only way to be sure there is no second copy is for the value never to have been anywhere but here.

You can check it rather than take it on trust: open your network tab and press Generate. Beyond the analytics beacon this site sends on every page load — a URL and a page title, the same as any other page here — nothing is requested. Disconnect from the network entirely and the generator still works, which is the simplest proof there is nothing on the other end to send to.

How long should a token be?

Length is the setting that matters. Each extra character multiplies the number of possible tokens by the size of the character set, so strength grows exponentially with length and only linearly with how exotic the alphabet is. Adding symbols to a 16-character token buys roughly as much as adding two or three characters to it.

The usual measure is entropy in bits, shown next to the button as you drag the slider. A rough scale: 32 bits is trivially breakable and belongs to throwaway identifiers only; 64 bits is out of reach of casual attempts but not of a serious one; 128 bits is the standard floor for anything protecting real access, and is what a 22-character token from the full alphanumeric set gives you; 256 bits is the level at which the number of possibilities stops having any physical comparison and no amount of hardware helps.

Practical guidance: for an API key, a session secret, a webhook signing key or an application key in a configuration file, 32 to 64 characters is right and the default of 64 is a good place to stay. For a database or service account password, 24 to 32 characters is usually the sweet spot between strong and pasteable. Short lengths — under 12 — are for identifiers, coupon codes and test fixtures, not for anything that guards access. The slider goes to 512 because some systems want a very long shared secret, and because there is no reason for the tool to have an opinion below the point where the browser starts to feel it.

Why symbols are off by default

Symbols add a little strength and a lot of friction, so the switch starts off.

The friction is mundane and expensive. A token containing $ or a backtick behaves differently once it is inside a shell script or a Docker environment file, where those characters are interpreted rather than stored. A token containing @, : or / breaks a database connection string, because those are the characters the URL format uses to separate the parts. Configuration files in YAML or INI have their own opinions about quoting. Some enterprise systems reject characters they consider unsafe, silently truncate at the first one, or accept the token on the way in and normalise it on the way out — which produces a credential that is wrong in a way nothing reports.

The set used here, when you do switch it on, deliberately leaves out the quote characters and the backslash for exactly that reason. But the real answer is the previous chapter: if you need more strength, add characters rather than punctuation. A 64-character alphanumeric token is already far beyond anything symbols would rescue, and it survives being pasted into every one of those places unchanged.

Switch symbols on when a policy demands them — plenty of password rules still do — or when the token is going straight into a password manager and no shell, connection string or config file will ever have to parse it.

Tokens are not passwords

The output here suits both, but the two are used differently and it is worth being clear about which you are making.

A token — an API key, a webhook secret, an application key — is read by machines. Nobody types it, so length costs nothing and there is no reason to be modest: generate long, paste once, store it in a secret manager or an environment variable, and never in a repository. Rotating it should be a routine operation rather than an emergency one, which in practice means the system reading it should tolerate two valid values while the change rolls out.

A password is entered by a person, at least occasionally, and is nearly always kept in a password manager. Random beats clever here: a generated string has no personal detail in it, no reused pattern, and nothing an attacker can guess from what they already know about you. If you do have to read one aloud or type it from a phone screen, a shorter length with lower case and numbers is far kinder than a symbol-heavy one, and 20 random characters is plenty.

Neither is improved by being memorable, and neither should be reused. The reason password reuse is the single most costly habit in security is that it converts one breach anywhere into access everywhere, and a generator exists precisely so that using a fresh value each time costs nothing.

A worked example

Leave the defaults — upper case, lower case and numbers, 64 characters — and press Generate. The header reads 64 characters, names the three sets, and reports 62 characters to choose from and roughly 381 bits of entropy. That is a token with no realistic prospect of being guessed by any means, from any hardware, in any timeframe, and it will paste unchanged into a .env file, a shell command, a connection string and a JSON body.

Now drag the slider to 20 and generate again: the same alphabet gives about 119 bits, which is still past the level at which brute force is a serious idea, and it is short enough to read off a screen. Switch symbols on and it becomes about 129 bits — a real gain, but less than the four extra characters you could have added instead, and now the value needs quoting in a shell. That comparison is the whole argument for the defaults on this page.