Random Token Generator
Generate unguessable tokens for password-reset links, sessions, invitations, CSRF protection or webhook secrets. Choose the strength in bits and the encoding, from hexadecimal to URL-safe Base64URL, and generate up to 100 tokens. Bytes come from your browser’s cryptographic random generator and are never sent anywhere.
- Runs in your browser
- No sign-up
- Free to use
Tokens are created in your browser and never sent or stored. Do not reuse a token shown here for a production system if anyone else could have seen your screen.
How to use Random Token Generator
- Choose the strength; 128 bits is the minimum for secrets, 256 is common.
- Choose the format your system expects.
- Generate the number of tokens you need.
- Copy a token into your configuration or code.
Random Token Generator features
64 to 512 bits
Byte-exact strength for each token.
Five encodings
Hex, Base64, Base64URL, Base32 and letters with digits.
URL-safe option
Base64URL without padding for links and headers.
Cryptographic source
crypto.getRandomValues; never Math.random.
Batch
Up to 100 tokens at once.
Private
No network requests and no storage.
When to use Random Token Generator
- Creating password-reset or e-mail verification tokens for testing.
- Generating a webhook signing secret.
- Setting a CSRF or session secret in configuration.
- Producing invitation codes that cannot be guessed.
Random Token Generator FAQ
How many bits should a token have?
At least 128 bits for anything that grants access on its own. 256 bits is a common, generous choice. 64 bits suits only identifiers that are not secret.
Which format should I use?
Hex is simple and widely accepted. Base64URL is shorter and safe in URLs and HTTP headers. Base32 is case-insensitive and good for codes people may read aloud.
Is a UUID a good token?
A random version 4 UUID has 122 bits of randomness, but some libraries and versions are not random. A dedicated random token makes the intent and the strength explicit.
Should I generate production secrets in a browser?
The randomness is as good as a server’s, but your screen and clipboard are exposed. Prefer generating production secrets on the server or with your platform’s secret manager.
Are the tokens stored?
No. They exist only in this page until you close it.
How should tokens be stored in a database?
Store a hash of the token, such as SHA-256, not the token itself, so a database leak does not expose working tokens.
Tokens are passwords for machines
A token is a secret value that grants something on its own: the ability to reset a password, to stay logged in, to call an API, to accept an invitation. Because whoever holds it gets the access, it must be impossible to guess, which means generated with a cryptographic random source and long enough to resist brute force.
Strength is measured in bits of randomness. With 128 bits there are about 3.4 × 10³⁸ possible tokens, and an attacker guessing billions per second would need far longer than the age of the universe. The encoding does not change the strength; it only changes how the bytes are written down.
Choose the encoding for where the token travels. Hexadecimal is unambiguous and easy to inspect. Base64URL is compact and safe in URLs, cookies and headers. Base32 avoids lower case and can be read over the phone. All are generated here from the same random bytes.
Handle tokens like passwords. Send them only over HTTPS, give them an expiry, invalidate them after use where possible, and store only their hash on the server. Generate production secrets in a controlled environment, not on a shared screen.