🔏 Security

CSP Hash Generator for Inline Scripts

Generate the SHA-256/384/512 base64 hash of an inline script to allow it in your Content-Security-Policy (CSP) without using a nonce. Harden your site security.

Algorithm Inline script content (paste exactly what sits between the script tags) Hash for CSP

—

Allowing an inline script without giving up your CSP

A Content-Security-Policy that includes unsafe-inline in script-src is, for practical purposes, switched off against XSS: any injected script on the page will run. Yet nearly every site has a handful of legitimate inline scripts — the analytics snippet, a configuration block, a form handler. Hashes settle that standoff: you authorise that exact content, and nothing else.

Paste the script content — only what sits between the tags, not the tags themselves — pick the algorithm, and the page returns the reference ready to use in the 'sha256-…' format, along with the full header line. The hash is computed by the browser's own WebCrypto and the result comes out in base64, exactly as the CSP specification expects.

The detail that sinks most attempts is byte-for-byte exactness. One extra space in the indentation, a trailing newline your editor added, a comment removed afterwards: any difference changes the hash and the browser blocks the script. Copy the content from the HTML as served, not from the source file, and check the console to see which hash the browser expected — it prints the correct value in the blocking message.

Frequently asked questions

Does the hash cover the opening and closing tags as well?

No. It covers only the text between the opening and closing tags. Attributes such as type or id stay out, and changing them does not invalidate the hash — but changing any character of the body, whitespace included, does.

Hash or nonce, which should I use?

Hashes work well for static content that does not change between requests, because you compute once and drop it into the policy. A nonce is better when the script is generated dynamically: the server draws a fresh value per response and repeats it in the nonce attribute. What does not work is a fixed nonce, which is equivalent to allowing everything.

Does this work for inline CSS and for onclick handlers?

For an inline style block, yes, with the same syntax under style-src. For HTML event attributes such as onclick, hashes do not apply: they only run with unsafe-inline, and the recommended route is moving them to addEventListener inside a script the policy already allows.

Related Tools

🔐

HMAC Generator

Generate HMACs (Hash-based Message Authentication Codes) with MD5, SHA-1, SHA-256, SHA-384, SHA-512 and SHA-3 algorithms.

🛡️

Trusted Types Policy Builder

Generate CSP require-trusted-types-for and trusted-types directives with policy names — a modern anti-XSS mitigation.

🛡️

Basic CSP Evaluator

Evaluates a Content-Security-Policy directive reporting unsafe-inline, unsafe-eval or wildcard issues.

🔐

Bcrypt Hash Generator

Generate secure bcrypt hashes from passwords and verify whether a password matches an existing bcrypt hash.

🎲

Secure CSP Nonce Generator

Generate a 128-bit base64 random nonce for Content-Security-Policy with sample header and <script nonce> attribute.

🔒

Content-Security-Policy Builder

Build a Content-Security-Policy header by adding directives (default-src, script-src, img-src, frame-ancestors) with predefined sources.