What a Token Maker Is, In One Paragraph
A token is an unguessable string a system uses to identify something — an API request, a session, a one-click magic link, a password reset. Token Maker generates those strings with cryptographically secure entropy: every character is drawn from crypto.getRandomValues, the same source recommended by OWASP for session IDs. You pick the length, the character set, and an optional vendor-style prefix; the tool produces one token or a batch of fifty.
It's not a replacement for the Password Generator (which is tuned for human-typed passwords with strength meters and visibility toggles). It's a replacement for opening a Node REPL and typing require('crypto').randomBytes(32).toString('hex').
How the Microapp Token Maker Works
Drag the slider to set the length (8 to 128 characters). Pick a character set — alphanumeric is the universal default, hex for URL-friendly strings, base64-url for what JWTs and OAuth tokens use, numeric for SMS-style verification codes, uppercase-hex when you need machine-readable HEX. Add an optional prefix like tk_, sk_live_, pk_ — Stripe popularized this; modern APIs use it because the prefix tells you what kind of token it is at a glance. Set the quantity if you need to seed multiple tokens at once. Click Generate; copy individual tokens or copy the whole batch.
Every byte of randomness comes from crypto.getRandomValues. There's no Math.random anywhere in the path — that one would be predictable enough to brute-force in seconds. Nothing leaves your browser; the tokens you see are the only copy that exists.
sk_test_, length 24, alphanumeric. Result: sk_test_aB8cD9eF1gH2iJ3kL4mN5oP6 ×20. Drop them into your fixtures table; each one is collision-resistant for the lifetime of the universe.
What Token Length Actually Means
Token security isn't about the length — it's about the entropy. A 32-character alphanumeric token has 6232 possible values, which is roughly 1057. To brute-force one, an attacker would need to check more tokens than there are atoms in the observable universe. That's "longer than the heat-death of the universe" secure.
For most uses, 32 alphanumeric characters is the sweet spot: long enough to be unguessable, short enough to log without filling the line, easy to copy by triple-click. Going to 64 doesn't add real security — it adds storage and visual clutter. Going below 16 starts to be brute-forceable for high-value targets.
Which Character Set To Pick
| Character set | Best for | Why |
|---|---|---|
| Alphanumeric | API keys, session IDs | Universal default — works everywhere, no escaping needed |
| Hex (lowercase) | URLs, file names | URL-safe, no case confusion |
| Base64-url | JWTs, OAuth tokens | Wider alphabet = more entropy per character |
| Numeric | SMS verification codes | Easy to type on a numeric keypad |
| Uppercase hex | Machine logs, database IDs | Readable in monospace; standard for many systems |
What the Prefix Is For
A token prefix like tk_, sk_live_, or ghp_ tells anyone who finds the token in a log, in source control, or in a Slack message what kind of secret it is. Stripe started this practice — sk_ means secret key, pk_ means publishable, _live_ versus _test_ tells you the environment. GitHub adopted it (ghp_, gho_, ghs_). Slack does it (xoxb-, xoxp-).
It's a small touch that prevents enormous incident-response confusion: when a junior engineer accidentally commits a token to a public repo, the prefix tells the security team within seconds whether they need to rotate a production payment key or just a sandbox API token. Worth the four extra characters.
Common Pitfalls
Using Math.random. Tempting because it's two characters shorter to type. Catastrophic because Math.random is a deterministic PRNG seeded from system state — given enough samples, an attacker can predict the next value. Never generate tokens with Math.random. The Token Maker uses crypto.getRandomValues exclusively for this reason.
Storing tokens in plaintext. Tokens act like passwords — they grant access. Store them hashed (bcrypt, Argon2) on the server, send them to the client once at creation, and let the client store the value. If your database is breached, hashed tokens are useless to the attacker.
No expiration. Tokens that never expire become permanent risk. Always set an expiration (exp claim for JWTs, a TTL on the database row otherwise) and force re-issue periodically.
Reusing the same secret across environments. Production tokens should be different from staging which should be different from development. The prefix convention helps enforce this — if your dev environment accidentally generates a sk_live_ token, that's a glaring red flag.
Related Tools
For human-typed passwords with a strength meter, use the Password Generator. For unique IDs (UUIDs) used as primary keys in databases, the UUID Generator is the right choice. To hash a token before storing it, the SHA-256 Generator covers most use cases. For one-time codes (TOTP / 2FA), see the OTP Generator. For structured signed tokens with a payload (JWTs), use the JWT Token Generator.