Random Token Generator
Random Token Generator bounds the requested length to 4–1,024, generates that many cryptographically random bytes, converts them to lowercase hexadecimal, and then keeps only the requested number of characters. Consequently the field controls hexadecimal character count, not byte count: a 32-character token carries 16 bytes (128 bits) of represented randomness, while odd lengths end on a half-byte. It provides no Base64url mode, policy estimate, storage, rotation, or secret handling.
Runs locally — files stay on your deviceHow much entropy is in a 32-character output?
The represented hexadecimal token contains 128 bits, assuming a sound browser random source.
Two hex characters represent one byte
Each hexadecimal character represents four bits. Although the implementation generates more random bytes than it displays, only the returned characters count toward the token's usable entropy.
How it works
Length is clamped to 4–1,024, crypto.getRandomValues fills that many bytes, bytes become hex, and slice keeps exactly the requested number of characters.
Key concepts
Character count
N hex characters represent 4N bits.
Minimum and maximum
Requests clamp to 4 and 1,024 characters.
When to use it
- Create a random hexadecimal test secret.
- Generate a nonce where the protocol expects hex.
- Produce a copyable opaque token.
When not to use it
- Do not assume the field is measured in bytes.
- Do not paste production secrets into logs or tickets.
- Do not use output without server-side storage and lifecycle controls.
Worked examples
128-bit token
- Input
Length 32- Expected output
32 lowercase hex characters
32 × 4 = 128 bits.
Odd length
- Input
Length 5- Expected output
5 hex characters
The last character represents one nibble.
Too small
- Input
Length 2- Expected output
4 characters
The minimum applies.
Common mistakes
Reading length as bytes
Only half as many displayed bytes are represented for even lengths. Correction: Use two hex characters per desired byte.
Using weak storage
Strong generation cannot protect leaked secrets. Correction: Store and transmit tokens securely.
No expiry or rotation
The page only generates text. Correction: Implement lifecycle policy in the application.
Best practices
- Choose entropy for the threat model.
- Use even lengths for whole-byte hex.
- Transmit securely, store hashed when appropriate, and support revocation.
Related operations and differences
Base64 Decoder
Choose Base64 Decoder when you need to decode Base64 into readable text.; use Random Token Generator specifically for random token.
Base64 Encoder
Choose Base64 Encoder when you need to encode text as Base64 in your browser.; use Random Token Generator specifically for random token.
Binary to Text
Choose Binary to Text when you need to decode 8-bit binary groups into text.; use Random Token Generator specifically for random token.
Hex to Text
Choose Hex to Text when you need to decode hexadecimal bytes into text.; use Random Token Generator specifically for random token.
HTML Escape
Choose HTML Escape when you need to escape HTML-sensitive characters.; use Random Token Generator specifically for random token.
HTML Unescape
Choose HTML Unescape when you need to decode HTML entities into characters.; use Random Token Generator specifically for random token.
Limitations and privacy
- Hex only; 4–1,024 characters, no byte-length label, Base64url, strength estimator, prefix, expiry, hashing, persistence, rotation, or revocation.
- Extra generated bytes beyond the slice are unused.
The entered value is transformed locally in this browser and is not sent to the Toolbox server.
Copying or pasting sensitive output into another service is a separate disclosure decision.
Frequently asked questions
Is output lowercase?
Yes.
Does length mean bytes?
No, it means returned hex characters.
Can length be odd?
Yes.
Is a generated token stored?
No.