By Updated

CSP Nonce & Hash Generator

Generate cryptographically-random CSP nonces and SHA-256/384/512 hashes for inline <script> and <style> sources. Bulk-hash several inline snippets at once.

Interactive tool

Input

16 bytes (128 bits) is the spec-recommended baseline.

Output

Adjust the byte length / count to generate nonces.

What is the CSP Nonce & Hash Generator?

Two tools in one. Nonce mode generates cryptographically-random nonces in the exact 'nonce-...' form CSP expects, with configurable byte length and bulk count. Hash mode computes SHA-256 / SHA-384 / SHA-512 hashes of inline <script> or <style> bodies in the 'sha256-...' source form. Paste several snippets at once and get all the matching CSP sources.

How to Use the CSP Nonce & Hash Generator

  1. 1Pick nonce mode or hash mode
  2. 2Nonce mode: choose byte length (16 bytes / 128 bits recommended) and how many nonces to generate. Copy the cspSource value into your CSP script-src list
  3. 3Hash mode: paste each inline <script> or <style> body on its own row. The tool computes the 'sha256-...' source for each: paste those directly into your CSP
  4. 4For hash mode: the body must match the served HTML byte-for-byte (including whitespace) (even a trailing newline breaks the hash)
What you get

Key features

Cryptographically-secure nonces

Uses Web Crypto getRandomValues. 16-byte (128-bit) default is well above the spec-recommended minimum.

Three hash algorithms

SHA-256, SHA-384, SHA-512. CSP accepts all three; sha256 is the de-facto standard.

Bulk hashing

Paste multiple inline-script bodies: one per row, separated by ---, and get all their CSP source values at once.

Drop-in CSP sources

Output values include the surrounding apostrophes ('sha256-...' / 'nonce-...') so they paste directly into a script-src list.

Pure-client

No data is sent to a server. Random bytes come from your browser, hashing happens in Web Crypto.

Why use nonces or hashes?

A modern CSP avoids 'unsafe-inline' by allowlisting each inline script via either a per-request nonce or a content-hash. Nonces are easier (single random value per request, sprinkled across every inline <script>); hashes are simpler when the inline content is static across requests.

Common use cases

  • Generating a one-off nonce for a quick proof-of-concept page
  • Producing the production-time hash for a CSP that locks down a Google Analytics inline snippet
  • Bulk-hashing every inline <script> on a static export before shipping
  • Generating nonces for templating engines that need to inject the same value into both the CSP header and every inline tag

Nonce vs hash, which to pick?

  • Nonces: simpler. One fresh value per request, injected via your server-side renderer into both the CSP header and every inline tag's nonce attribute. Pair with 'strict-dynamic' so allowlisted scripts can load further scripts.
  • Hashes: useful for static sites that cannot easily inject a per-request value. The catch is that any change to the inline body invalidates the hash, so you must regenerate after edits.

Whitespace matters

Hashes are byte-exact. Whitespace, newlines, BOMs, and HTML escaping all change the hash. Paste exactly what the browser will receive: copy directly from the rendered HTML if in doubt.

Pro tips

Tips & best practices

16-byte nonces, refreshed per request

Anything shorter than 16 bytes (22 base64 characters) is rejected as MEDIUM by Google CSP Evaluator. Always regenerate per request.

Never reuse a nonce across requests

A nonce is only secure if it is unguessable. Caching the value defeats the purpose.

Combine nonces with strict-dynamic

Modern policies pair 'nonce-...' with 'strict-dynamic' so allowlisted inline scripts can dynamically load further scripts. Use the CSP Generator to assemble the matching policy.

Built for trust

Privacy & security

This tool runs entirely in your browser. Nonces are generated locally and hashes are computed via Web Crypto.

Frequently Asked Questions

What byte length should I use for a nonce?

16 bytes (128 bits) is the spec-recommended baseline. 12 bytes is still secure but tighter than Google CSP Evaluator likes; 32 bytes adds belt-and-braces with no downside.

Does the hash need to include the <script> wrapper?

No: only the inline body. Browsers hash exactly the text content of the <script> or <style> element. Strip the opening/closing tags before pasting.

Why did my hash stop matching?

Any change to the inline body invalidates the hash, including whitespace, line endings, BOMs, and HTML entity escaping. Re-generate after every edit.

Should I use sha256, sha384, or sha512?

sha256 is the de-facto standard and gives the shortest CSP source. The other two work identically; choose them only if your security policy mandates them.

Is the random source cryptographically secure?

Yes. We use Web Crypto's crypto.getRandomValues, which is the same source modern browsers and Node use for TLS keys.