Nonce Generator

A nonce — short for "number used once" — is a randomly generated value that plays a foundational role in modern cryptography and web security. The defining property of a nonce is that it must never be reused within the same security context. Once a nonce has been consumed in a protocol exchange, reusing it can expose secrets, allow replay attacks, or undermine the entire security guarantee that the nonce was designed to provide.

Nonces appear in an enormous range of security-critical scenarios. In TLS handshakes, client and server each contribute a random nonce to prevent an eavesdropper from reusing recorded traffic. In OAuth 2.0 and OpenID Connect, a nonce bound to the authentication request prevents token substitution attacks. In HTTP Content Security Policy (CSP), script nonces allow specific inline scripts to execute while blocking injected malicious code. In challenge-response authentication, the server issues a fresh nonce that the client must sign, proving possession of a secret without transmitting it.

The security of all these mechanisms depends directly on the unpredictability of the nonce. If an attacker can predict the next nonce, they can forge tokens, bypass CSP protections, or mount replay attacks. This is why nonces must be generated using a cryptographically secure pseudorandom number generator (CSPRNG) — not Math.random() or any other general-purpose random source. This calculator uses the browser's built-in crypto.getRandomValues() API, which draws from the operating system's CSPRNG and is suitable for security-sensitive applications.

Nonce length also matters. An 8-byte (64-bit) nonce provides approximately 1.8 × 10¹⁹ possible values — large enough for most applications, but a 32-byte (256-bit) nonce gives a astronomically larger space and is recommended for long-lived systems or high-volume token issuance where birthday-paradox collisions become a practical concern. As a rule of thumb, choose at least 16 bytes (128 bits) for general use and 32 bytes for high-security environments.

This nonce generator uses the Web Cryptography API's crypto.getRandomValues() function, which fills a typed array with cryptographically secure random bytes sourced from the operating system entropy pool. The raw bytes are then encoded into the chosen output format. No server requests are made — all generation happens locally in your browser, so nonces are never transmitted or logged.

The generator supports five output formats to match different integration requirements:

• Hexadecimal (hex): Each byte is converted to a two-character lowercase hex string (e.g., byte value 255 becomes "ff"). A 16-byte nonce produces a 32-character hex string. This is the most common format for tokens and session identifiers.
• Base64: The raw bytes are encoded using standard Base64 (RFC 4648). A 16-byte input produces a 24-character Base64 string (including padding "=" characters). This format is compact and widely supported in HTTP headers.
• Base64 URL: URL-safe Base64 replaces "+" with "-", "/" with "_", and strips padding "=" characters. This makes the nonce safe to embed directly in URLs and JWT headers without percent-encoding.
• Decimal: Each byte (0–255) is zero-padded to three digits and concatenated. A 16-byte nonce produces a 48-digit decimal string. This format is useful when only numeric characters are acceptable.
• UUID: The first 16 bytes are formatted as a UUID string (8-4-4-4-12 hex groups). Note that this tool generates random UUID-like strings from secure random bytes; the version and variant bits are not set per RFC 4122, so the output should not be treated as a standards-compliant UUID v4.

You can also enable a timestamp prefix. When enabled, the current Unix timestamp in milliseconds is converted to Base-36 (using Date.now().toString(36)) and prepended to the nonce with a hyphen separator. This makes nonces time-sortable and enables approximate issuance-time recovery without storing metadata separately — useful for token auditing and short-lived credential systems.

The output character count varies by both the byte length you select and the output format. Understanding the relationship helps you allocate the right amount of storage or column width in your database or configuration system. The table below shows the exact output length for each combination:

Note that the UUID format always produces 36 characters regardless of byte length, because it uses only the first 16 bytes and formats them in the fixed 8-4-4-4-12 hyphenated pattern. If you need variable-length output that scales with byte count, use hex, Base64, or decimal instead.

When designing a system that stores nonces (e.g., in a database for CSRF token validation or OAuth state parameter tracking), choose a column type wide enough for the largest format you might use. A VARCHAR(96) covers all formats up to 32 bytes, or use VARCHAR(128) for future headroom when the timestamp prefix is enabled.

Understanding where nonces are used in practice helps you choose the right settings for your specific integration. Different protocols have different expectations for nonce format, length, and uniqueness guarantees.

Content Security Policy (CSP) Script Nonces

The CSP script-src 'nonce-...' directive allows inline scripts only when their nonce attribute matches the server-generated value in the CSP header. The nonce must be a fresh, cryptographically random value on every page load — never a static string. A 16-byte Base64 URL nonce (22 characters) is typical. Reusing a CSP nonce across requests defeats its purpose and exposes users to XSS attacks.

CSRF Protection Tokens

Cross-Site Request Forgery (CSRF) tokens are nonces tied to a user's session. The server embeds the token in a form or custom header, and the server validates that incoming requests carry the matching value. A 16–32 byte hex nonce stored server-side per session is the standard approach. The "double submit cookie" pattern uses the nonce both in a cookie and a form field, verifying they match without server-side storage.

OAuth 2.0 and OpenID Connect State Parameter

The state parameter in OAuth 2.0 authorization requests is a nonce the client generates, stores locally, and verifies upon callback. It prevents CSRF against the OAuth flow. A 16-byte Base64 URL nonce (22 characters) is the recommended format because it is URL-safe and compact enough for query parameters without percent-encoding.

Replay Attack Prevention in APIs

APIs that sign requests (HMAC-SHA256, AWS Signature v4, etc.) include a nonce and timestamp in the signed payload. The server caches seen nonces for a short window (e.g., 5 minutes) and rejects any request that presents a previously used nonce within that window, even if the signature is otherwise valid. A 12–16 byte hex or Base64 nonce provides sufficient uniqueness for high-throughput APIs without excessive storage overhead.

Encryption Initialization Vectors (IVs)

In symmetric encryption modes like AES-GCM, the 12-byte (96-bit) initialization vector must be unique per encryption operation with a given key. Generating a fresh random IV for every encrypt call using a CSPRNG — exactly what this generator does — is the standard practice recommended by NIST SP 800-38D. Reusing an IV with the same key in GCM mode can expose the authentication key and allow forgeries.

Generating a cryptographically strong nonce is only half the battle. How you store, transmit, validate, and expire nonces determines whether your system is actually secure. The following best practices cover the full lifecycle of a nonce from generation to retirement.

Always use a CSPRNG. General-purpose random functions like JavaScript's Math.random(), Python's random.random(), or PHP's rand() are not cryptographically secure. They may be seeded with predictable values or have internal state that an attacker can reconstruct. Always use crypto.getRandomValues() in browsers, crypto.randomBytes() in Node.js, secrets.token_bytes() in Python, or the equivalent OS-level secure random source.

Match nonce length to your threat model. For most web application use cases (CSRF tokens, CSP nonces, OAuth state), 16 bytes (128 bits) provides an astronomically small collision probability even under heavy load. For high-security applications, cryptographic keys, or long-lived tokens, prefer 32 bytes (256 bits). Shorter nonces (8 bytes / 64 bits) may be acceptable for short-lived, low-value tokens where storage is constrained.

Enforce single use. A nonce that can be reused is not a nonce — it is a static token. Implement server-side tracking of consumed nonces within the validity window. For short-lived nonces (under 5 minutes), a Redis set or in-memory cache with TTL expiry is efficient. For long-lived nonces (session tokens, invitation links), a database column with a "used" flag or deletion on consumption is appropriate.

Set expiration times. Nonces should expire after a reasonable window. CSRF nonces typically expire with the session. One-time invitation link nonces should expire after 24–72 hours. CSP nonces expire with the page response. Never issue nonces that are valid indefinitely — this creates a growing attack surface as the list of valid nonces grows.

Transmit nonces over encrypted channels only. A nonce intercepted in transit can be replayed by the interceptor. Always use HTTPS/TLS when transmitting nonces in headers, cookies, or request bodies. Set the Secure flag on cookies that carry nonce values to prevent transmission over plain HTTP.

Do not log nonces verbatim in application logs. Application logs are often shipped to monitoring systems, stored long-term, and accessible to more personnel than security tokens should be. Hash nonces (SHA-256) before logging if you need audit trails, so that the log entry cannot be replayed even if the log is compromised.