What is a random hex string?
It's random binary data written in hexadecimal, two characters (0 to 9 and a to f) per byte. Because hex is compact and safe in URLs, filenames, headers and JSON, it's the usual format for tokens, salts, nonces and test identifiers. This generator draws 1 to 256 bytes from your browser's cryptographically secure generator and prints them as one lowercase hex string.
Using the generator
- Set Length (bytes) between 1 and 256. The default is 16.
- Click Generate.
- Copy the string; it has no spaces,
0xprefix or line breaks.
Example output
With the default of 16 bytes:
591da2a21680d6ea36c1d616332a04b7
That's 32 characters encoding 128 random bits. Each pair is one byte: 59 is 89, 1d is 29, a2 is 162, and so on. Single-digit bytes are zero-padded, so a byte of 5 appears as 05 and the length is always exactly twice the byte count.
Choosing a length
| Bytes | Hex characters | Bits | Typical use |
|---|---|---|---|
| 3 | 6 | 24 | A random CSS colour such as #7998b9 |
| 8 | 16 | 64 | The minimum for session secrets in NIST SP 800-63B |
| 12 | 24 | 96 | A nonce for AES-GCM |
| 16 | 32 | 128 | API tokens, request IDs, CSRF tokens |
| 32 | 64 | 256 | Long-lived secrets, HMAC keys, a SHA-256-sized placeholder |
| 256 | 512 | 2048 | The maximum; test payloads |
The 64-bit figure comes from section 7.1 of NIST SP 800-63B, which says session secrets "SHALL be generated by an approved random bit generator" and contain at least 64 bits of entropy. In my view 128 bits is the better default for anything you'd be upset to see guessed: it costs 16 extra characters and makes the question moot. The 12-byte row reflects NIST SP 800-38D, which recommends 96-bit IVs for GCM; never reuse one with the same key.
The three-byte row is a fun one. Prefix the result with # and you have a random colour; 7998b9 came out of the tool and the hex to RGB converter reads it as rgb(121, 152, 185), a muted blue.
How likely is a collision?
For random tokens, the risk to think about is two tokens accidentally being identical. With 128 bits, the birthday bound puts a 50% chance of any collision at around 2.2 × 10¹⁹ tokens. Even a system minting a million tokens a second would need several hundred thousand years to get there. At 64 bits that drops to about 5 billion tokens, which a busy service can actually reach, another reason to prefer 16 bytes for identifiers.
Hex string versus UUID versus hash
These three look alike and get mixed up:
- Random hex (this tool): every bit is random; any length you like.
- UUID v4: 122 random bits plus 6 fixed bits, formatted with hyphens, as defined in RFC 9562 section 5.4. The UUID generator makes those.
- Hash: not random at all. A SHA-256 digest is 64 hex characters derived from an input, and the same input always gives the same digest. The hash generator computes those.
If a database column or API expects a UUID, give it a UUID. If you need a secret or an unguessable ID with no format constraints, random hex is simpler and carries slightly more randomness per 128 bits.
How it's generated
The tool fills a byte array with crypto.getRandomValues and converts each byte with toString(16), padded to two digits. There's no rounding or range mapping, so every hex digit is uniformly distributed. Nothing is sent to a server.
One limitation is practical rather than technical: a value you copy from a web page has been displayed on screen and sat in your clipboard. That's fine for test fixtures, development secrets and one-off tokens. For production keys, generate the value inside the system that stores it, using its own secure random source.
If you'd rather see the same random bytes as decimal numbers (to paste into an array literal, say), use the random byte generator.
Last updated