Secure Token Generator

How to use the Secure Token Generator

1. Pick a format: base64url for URL and header values that have to survive percent-encoding, hex when a system parses with parseInt(s, 16) or Buffer.from(s, "hex"), alphanumeric for forms that reject punctuation, and UUID v4 for record identifiers rather than secrets.
2. Drag the Length slider for non-UUID formats. The page recomputes entropy bits live so you can see when 64-bit, 128-bit, or 256-bit thresholds are crossed.
3. Drag Count if you need more than one. Generating ten at once is convenient when you need a primary, a rotation backup, and a few test fixtures.
4. Click Generate Tokens, then Copy All to copy the whole batch newline-separated, or click any token to select-all and copy a single value.
5. Move the value to its destination immediately. Stash it in a password manager, paste it into .env.local, or set the GitHub secret while the tab is still open. Tokens never leave the page, but they also never come back; refreshing wipes them.

What the generator does under the hood

All randomness comes from the Web Crypto API. UUID v4 calls crypto.randomUUID(), which all current Chromium, Firefox, and Safari builds back with their CSPRNG (BoringSSL on Chromium, NSS on Firefox, CommonCrypto on Safari). Hex, base64url, and alphanumeric formats fill a Uint8Array through crypto.getRandomValues() and then encode it: hex via byte.toString(16).padStart(2, "0"), base64url through btoa() with the URL-safe substitutions from RFC 4648 section 5 (+ becomes -, / becomes _, padding stripped).

Alphanumeric is the only format that needs care. A naive byte % 62 mapping is biased because 256 is not a multiple of 62, so bytes 248-255 map to a four-character window more often than the rest. The generator uses rejection sampling against a precomputed ceiling (Math.floor(256 / 62) * 62), discarding any byte that falls into the unbiased range. The entropy estimate displayed on the page comes from length * log2(alphabetSize), so 32 base64url characters report 192 bits, 32 hex characters report 128 bits, and a UUID v4 reports 122 bits (the four version and variant bits are fixed by RFC 4122).

When this tool earns its keep

• Seeding a fresh JWT_SECRET, SESSION_SECRET, or COOKIE_SIGNING_KEY for an Express, Hono, or Rails app you just scaffolded.
• Generating an opaque API key for an internal service before wiring up an issuer that does this properly with a database row.
• Producing a CSRF token for a manual fetch test against a staging endpoint, or a nonce for a one-off script-src CSP test.
• Creating an invite or activation code where you want at least 80 bits of entropy so that brute-force enumeration is unattractive.
• Filling in a webhook verification secret on a Stripe, GitHub, or Linear webhook configuration page that asks for a long random string.
• Scaffolding test fixtures (a thousand UUIDs for a load test, twenty hex secrets for a fuzz harness) without depending on a Node or Python install.

Common pitfalls and edge cases

• Hex strings are half the entropy of the same number of base64url characters. A 32-character hex token is 128 bits; a 32-character base64url token is 192 bits. Match the length to the threshold you need, not to a habit.
• UUID v4 is not a secret format. Only 122 of its 128 bits are random and the structure is well known, so leaking the prefix narrows guesses. Use base64url or hex for anything that grants access.
• Alphanumeric fits inside hostnames and case-sensitive forms, but URL-decoders sometimes uppercase or lowercase percent-encoded sequences and can corrupt mixed-case values. base64url is safer in URLs.
• Length truncation is exact. The generator slices the encoded output to the slider value, so a 32-character base64url token consumes a 24-byte source even though raw base64 would round to 32 bytes. Adjust your storage column accordingly.
• The clipboard write happens on the page thread. If your browser blocks navigator.clipboard.writeText in a non-secure context (HTTP without localhost), the Copy All button will silently fail. ZeroUtil ships HTTPS, so this only bites local proxies.
• Tokens persist only in tab memory. Refreshing the page clears them; they are never written to localStorage, IndexedDB, or a cookie. Treat them as ephemeral until you hit Copy.

Token formats and the standards behind them

Hex is the oldest of the four and the most spec-stable: it is a direct base-16 encoding of bytes, used by SHA-256 hex digests, MAC addresses, and most CLI openssl rand -hex N output. Base64url is defined by RFC 4648 section 5 and is the canonical encoding for JWT components, JWK thumbprints, OAuth bearer tokens, and any context where +, /, or = would clash with URL or filename rules. UUID version 4 follows RFC 4122 (now RFC 9562), which fixes the version nibble to 4 and the variant bits to 10, leaving 122 bits of randomness; collision probability passes the birthday bound after roughly 2.71 quintillion draws, which is why it is fine for primary keys but inadequate as an authentication secret.

Alternatives and when they beat this tool

On the command line, openssl rand -base64 24 and openssl rand -hex 16 produce equivalent output and integrate into shell pipelines. Node's crypto.randomBytes(24).toString("base64url") is the right call inside an application or seed script. Python's secrets.token_urlsafe(24) ships with the standard library and is the closest single-call equivalent. uuidgen exists on every Linux and macOS install for plain UUIDs. This page wins when you need a token while reading documentation in another tab, you do not want to paste a half-built secret into a shared terminal, and you do not want to send your would-be production key to a remote service like passwordsgenerator.net or 1password.com to be regenerated.