Generate cryptographically random nonces in hex or base64 for CSP headers, auth flows and testing.
Client-side randomness for development use. For production security tokens (sessions, CSRF, password resets), generate the nonce server-side.
How to use this tool
16 bytes hex is a good default; 32 bytes for higher-value tokens.
Each click makes a fresh nonce.
Use once per request or session, as the name implies.
Browser randomness is fine for dev; production tokens belong on the server.
Formula & worked example
16 bytes, hex gives a 64-character hexadecimal nonce (128 bits of entropy); base64url of the same length is 22 characters with no + or /.
Limitations — read this before you rely on it
Client-side randomness for development use only. A browser-generated nonce must not be treated as a production security token, and nonces are single-use by design — reusing one defeats its purpose.
Frequently asked questions
A number used once — a random value that should never be reused, used for sessions, CSRF tokens and one-time challenges.
Math.random is predictable and unsuitable for security values. Without crypto.getRandomValues, generation fails loudly instead of producing a weak nonce.
Hex is longest and easiest to read; base64url is shortest and safe in URLs without escaping.
For development, yes. Production security tokens should be generated server-side, where the secret never passes through the browser.
128 bits — far beyond brute force for a single-use token.