Generate access tokens, API keys and secrets locally — signed JWTs (HS256/384/512), random hex, base64url, alphanumeric strings and UUIDs, sized by entropy.
Use this free online Token Generator directly in your browser. No signup required, no data leaves your device. Part of Utilier — a collection of 139+ developer utilities.
What is Token Generator (JWT, Random Hex, Base64url, UUID)?
A token generator produces the opaque strings and signed tokens that authenticate requests, protect endpoints and identify sessions. This tool builds two families in your browser: signed JSON Web Tokens (JWT), where a header and JSON payload are HMAC-signed with a secret you supply, and opaque random tokens — hexadecimal, base64url, alphanumeric or UUID — drawn from the Web Crypto cryptographically secure random number generator.
Signed JWTs, not just decoded ones: Pick HS256, HS384 or HS512, paste a JSON payload, provide a secret, and the tool emits a complete header.payload.signature token. It sets iat automatically and adds an exp claim from the expiry you choose, so the token you copy is ready to hand to a bearer-auth endpoint.
Opaque tokens sized by entropy: Random hex, base64url and alphanumeric tokens are specified by byte length rather than character count, so a 32-byte token is 256 bits of entropy regardless of the encoding you read it in. That makes it easy to hit a target strength for an API key or CSRF token.
UUID v4 when you need an identifier: The UUID option produces version 4 identifiers from the same CSPRNG, for correlation IDs, idempotency keys or record primary keys where a globally-unique value matters more than unpredictability.
Everything stays local: Both the JWT signing (via the SubtleCrypto HMAC primitive) and the random generation happen in the page. No secret, payload or generated token is uploaded, which is what makes it safe to paste a real signing secret while you experiment.
Why use the Token Generator?
The right kind of token depends on the job, and getting the kind, length or algorithm wrong is a real security bug. A single tool that produces all the common shapes correctly saves you from hand-rolling weak ones.
Stop generating weak secrets by hand: Typing a memorable string as an API key or JWT secret is the most common cause of forgeable tokens. Generating from a CSPRNG at an explicit byte length removes guesswork and gives you a value with known entropy.
Prototype and test bearer auth quickly: When you are wiring up an Authorization: Bearer flow, a valid signed JWT with the right claims and expiry lets you exercise the endpoint immediately, then decode it in the JWT Decoder to confirm what the server sees.
Match the encoding your system expects: Some systems want URL-safe base64url (no +, / or =), some want lowercase hex, some want alphanumeric that survives a double-click select. Producing the same entropy in the encoding your config expects avoids transport bugs.
One place for keys, secrets and IDs: API keys, webhook signing secrets, session tokens, CSRF tokens and correlation IDs are all just random strings of a chosen shape. Generating them consistently keeps their strength predictable across a codebase.
When to use the Token Generator
Reach for it whenever you need a token, key or secret with a known shape and strength — and pair it with the decoder or a proper secrets manager for the parts a generator cannot do.
Creating a signing secret or API key for a new service, sized to a deliberate byte length rather than typed by hand.
Producing a valid signed JWT to test a bearer-token endpoint, with iat and exp already populated.
Generating a CSRF token, password-reset token or email-verification token that must be unpredictable.
Minting UUID v4 correlation or idempotency keys for logs, request tracing or retry-safe writes.
Choosing between hex, base64url and alphanumeric encodings when a config file or header has a specific format requirement.
Rotating a secret and needing a fresh high-entropy value on the spot, without leaving the browser.
How to use the Token Generator
Choose the token type, set its options, and copy the result — every value is generated locally.
Pick the token type: Use the Token type dropdown: JWT (signed) for a header.payload.signature token, or Random — Hex / Base64url / Alphanumeric, or UUID v4 for an opaque identifier. The options below change to match.
For a JWT, set the algorithm and claims: Choose HS256, HS384 or HS512, edit the JSON payload, set an expiry in seconds, and enter your signing secret. iat is added automatically and exp is derived from the expiry.
For a random token, set the byte length: Byte length controls entropy: 16 bytes is 128 bits, 32 bytes is 256 bits. Optionally add a prefix (for example sk_) and a count to generate several at once.
Generate: Click Generate. The status line reports the algorithm for a JWT, or the approximate bit strength for random tokens, so you can confirm you hit the target.
Copy or download: Use the Copy button on the output, or Download to save the tokens to a file. For a JWT, paste it into the JWT Decoder to verify the header and claims read back as expected.
Key features
Signed JWT output: HS256/384/512 signing via Web Crypto HMAC, with automatic iat and an exp derived from a configurable expiry.
Entropy-sized random tokens: Hex, base64url and alphanumeric tokens specified by byte length, so strength in bits is explicit and independent of the encoding.
UUID v4 generation: Version 4 identifiers from the same CSPRNG for correlation IDs, idempotency keys and unique record keys.
Prefixes and bulk output: Add a fixed prefix like sk_ and generate many tokens at once for seeding or load testing.
Cryptographically secure: All randomness comes from crypto.getRandomValues, never Math.random, so tokens are unpredictable.
Fully offline: Signing and generation run in the browser tab; no secret or token is sent to a server.
Common use cases
New service credentials: Mint an API key or webhook signing secret at a deliberate byte length when standing up a service.
Bearer-auth testing: Produce a valid signed JWT with the claims and expiry an endpoint expects, then decode it to confirm.
CSRF and one-time tokens: Generate unpredictable tokens for CSRF protection, password resets and email verification.
Tracing and idempotency: Create UUID v4 correlation and idempotency keys for request tracing and retry-safe writes.
Secret rotation: Get a fresh high-entropy replacement value on demand when rotating a leaked or expiring secret.
Examples
Representative outputs; random values differ on every run by design.
Version 4, RFC 4122 variant, from crypto.getRandomValues
Randomness source
Web Crypto crypto.getRandomValues (CSPRNG), never Math.random
Privacy
No network requests — signing and generation are local
Common mistakes to avoid
Using a short, memorable string as a JWT signing secret
Why it happens: HS256/384/512 sign with HMAC, whose security rests entirely on the secret being unguessable. A dictionary word or a 12-character password can be brute-forced offline against a single captured token in seconds to hours, after which an attacker can mint tokens with any claims — any user id, any role — and your server will accept them as genuine. The token looks the same whether the secret was strong or weak, so nothing warns you.
How to avoid it: Use this tool to generate the secret as well as the token: a 32-byte (256-bit) random value is the standard floor for HS256. Store it in a secrets manager or environment variable, never in source control, and rotate it if it is ever exposed. For multi-party or public-client scenarios prefer an asymmetric algorithm (RS256/ES256) so only the issuer holds the private key.
Treating the JWT payload as secret
Why it happens: A JWT's header and payload are base64url-encoded, not encrypted. Anyone holding the token can decode and read every claim without the secret — the signature only proves the claims were not altered, not that they are hidden. Putting a password, full personal record or internal flag in the payload leaks it to the client and to anything that logs the token.
How to avoid it: Put only non-sensitive identifiers and authorization claims (sub, role, scopes, exp) in the payload. Keep secrets server-side and look them up by the sub claim. If you genuinely need confidential data inside the token, use JWE (encrypted JWT) rather than a signed JWT, and always send tokens over HTTPS.
Confusing token length in characters with entropy in bits
Why it happens: A 32-character token can be anywhere from 32 bits to 190+ bits of entropy depending on the alphabet, and a token restricted to a small character set is far weaker than its length suggests. Sizing by character count leads to under-strength keys that pass a superficial length check but fall to brute force.
How to avoid it: Size random tokens by byte length, which this tool does: bytes × 8 = bits of entropy, independent of hex/base64url/alphanumeric encoding. Aim for 128 bits (16 bytes) minimum for session and CSRF tokens and 256 bits (32 bytes) for long-lived API keys. The status line reports the bit strength so you can confirm it.
Using a UUID where an unpredictable secret is required
Why it happens: UUID v4 is random but only carries about 122 bits of randomness and, more importantly, is designed for uniqueness rather than secrecy — it is fine as an identifier but was never intended as a bearer credential. Using one as a password-reset token or API key can be acceptable at 122 bits, but relying on version 1 or 3/5 UUIDs (time- or name-based) for that is dangerous because they are partly predictable.
How to avoid it: Use the Hex or Base64url token types for anything that must be secret, sized to 128 or 256 bits. Reserve UUIDs for identifiers — correlation IDs, idempotency keys, primary keys — where collision resistance, not unpredictability, is the requirement.
Frequently asked questions
Is it safe to paste my real JWT signing secret here?
Yes. The signing is performed in your browser using the Web Crypto SubtleCrypto HMAC primitive, and neither the secret nor the payload nor the resulting token is sent anywhere. You can confirm this in your browser's network panel: generating a token makes no requests. That said, treat any machine you do not control with caution, and rotate a secret if you ever generated it somewhere untrusted.
What is the difference between the JWT and the random token options?
A JWT is a structured, signed token: it carries a JSON payload of claims and a signature that lets a server verify the claims were not tampered with, using the shared secret. A random token (hex, base64url, alphanumeric) is opaque — it carries no data, and the server validates it by looking it up in a store. Use a JWT when the token should convey verifiable claims like a user id and expiry; use a random token for API keys, session identifiers and CSRF tokens that are just references.
How many bytes should my token be?
For secrets, 16 bytes (128 bits) is the practical minimum and 32 bytes (256 bits) is the common choice for API keys and JWT signing secrets. Because this tool sizes by byte length, the entropy is exactly bytes × 8 regardless of whether you read the value as hex or base64url. The status line shows the bit strength after each generation so you can match a policy that specifies a minimum.
Which encoding should I choose — hex, base64url or alphanumeric?
Use hex when a system expects lowercase hexadecimal (many signing secrets and hashes do); it is the most portable but the longest. Use base64url when the token goes in a URL, header or filename, because it avoids +, / and = and needs no escaping. Use alphanumeric when the value must survive a double-click selection or be typed by a human. All three carry the same entropy for a given byte length.
Does the JWT include standard claims automatically?
It sets iat (issued-at) to the current time and, when you provide a non-zero expiry, adds exp (expiry) as iat plus that many seconds. Any other claims come from the JSON payload you supply, so you can add sub, aud, iss, scopes or custom fields. Decode the result in the JWT Decoder to see exactly what the server will read.
Can I verify a token this tool created?
Yes — open the JWT Decoder, paste the token and provide the same secret to verify the HMAC signature. For random tokens there is nothing to verify cryptographically; a server checks them by comparing against a stored value, ideally with a constant-time comparison to avoid timing leaks.