Ready to generate
Configure options and click Generate// generate secure nonces and one-time tokens instantly
Generate cryptographically secure nonces for CSP headers, one-time tokens, and random secrets. Browser-based, free, no sign-up required.
Ready to generate
Configure options and click GenerateSelect Base64 for CSP headers, Hex for cookies/tokens, or Alphanumeric for URLs.
16–32 bytes is standard. Higher is stronger — 32 bytes is recommended for CSP nonces.
Click Generate and copy your nonce or the full CSP header snippet directly.
A nonce (number used once) is a cryptographically random value used to ensure a request or resource is fresh and untampered. In web security, CSP nonces allow specific inline scripts to execute while blocking all others — a key defense against XSS attacks.
A Content Security Policy nonce is a unique, randomly generated value added to a Content-Security-Policy HTTP header and to allowed <script> or <style> tags. The browser checks that the nonce in the CSP header matches the one in the tag before executing the script, blocking any injected or unauthorized code.
The OWASP CSP cheat sheet recommends at least 128 bits (16 bytes) of entropy. For maximum security, 256 bits (32 bytes) is a strong standard. This tool defaults to 32 bytes, which generates a ~43-character base64 string with plenty of randomness to prevent guessing.
This tool uses your browser's built-in crypto.getRandomValues() — the same cryptographically secure random source used by browsers everywhere. The values are never sent to a server. However, for production, you should generate nonces server-side on every request so each page load has a unique, unpredictable value.
Use Base64 for CSP nonces — it is compact and well supported. Use Hex when you need a lowercase string compatible with hash-based systems or cookies. Use Alphanumeric when the token needs to be URL-safe without any special characters (e.g. query parameters without encoding).
If the same nonce appears on multiple page loads, an attacker who observes one response can reuse that nonce to inject scripts on another page. Nonces must be freshly generated for every HTTP response. This tool is best used for testing or bootstrapping — use a server-side random generator (e.g. random_bytes() in PHP) in production.
No — CSP nonces work on <script> and <style> elements only. Inline event handlers like onclick="" are not covered. The recommended approach is to move all event handling to external scripts or use the strict-dynamic CSP directive alongside nonces.
A nonce — short for "number used once" — is a cryptographically random value that ties a piece of data (like a script element) to a specific HTTP response. The value is unique per page load, making it impossible for an attacker to predict or reuse it. Nonces are central to modern Content Security Policy (CSP) implementation and CSRF protection strategies.
💡 Looking for premium web development assets? MonsterONE offers unlimited downloads of templates, UI kits, and developer tools — worth checking out.
Content Security Policy is an HTTP response header that tells the browser which resources it's allowed to load and execute. Without a nonce or hash, enabling inline scripts requires the unsafe-inline directive — which defeats most of CSP's protection against Cross-Site Scripting (XSS) attacks.
With nonces, you can allow specific inline scripts while blocking everything else. The flow works like this:
abc123xyz) for every response.Content-Security-Policy: script-src 'nonce-abc123xyz'<script nonce="abc123xyz">Both nonces and hashes are CSP mechanisms to allow specific inline content without enabling unsafe-inline. The key difference is that a nonce changes with every request (dynamic), while a hash is computed from the script content itself (static). If your inline scripts change based on user data or request context, nonces are the right choice. If you have fixed, static inline scripts, hashes can work well too — they don't require server-side generation per request.
Not all random values are equal. For security, nonces must come from a cryptographically secure pseudo-random number generator (CSPRNG). Using a weak PRNG — like PHP's rand() or JavaScript's Math.random() — is dangerous because the output can be predicted. This tool uses the browser's crypto.getRandomValues() API, which is cryptographically secure and appropriate for security-sensitive values.
When implementing nonces in production, use your language's secure random function:
base64_encode(random_bytes(32))crypto.randomBytes(32).toString('base64')secrets.token_urlsafe(32)SecureRandom.base64(32)Nonces also appear in CSRF (Cross-Site Request Forgery) protection. A server generates a unique token per session or per form, embeds it as a hidden field, and validates it on submission. Because the attacker's site cannot read the nonce from your page (due to the Same-Origin Policy), any forged request will fail validation. Frameworks like Laravel, Django, and Rails implement this pattern automatically.
The strength of a nonce depends on its entropy — the number of possible values. With 16 bytes (128 bits) of randomness, there are 2128 possible nonces. Even with a billion requests per second, an attacker would need trillions of years to guess one. For most applications, 16–32 bytes is more than sufficient. The W3C CSP specification recommends at least 128 bits (16 bytes); 32 bytes (256 bits) is a conservative choice for high-security contexts.
The strict-dynamic CSP directive pairs well with nonces. It allows scripts loaded by a trusted, nonce-bearing script to also run — without needing their own nonces or being individually allowlisted. This is useful in modern web apps where a trusted entry-point script dynamically loads other scripts at runtime. The combination of a server-generated nonce plus strict-dynamic provides strong XSS protection while keeping CSP maintainable.