How to Generate SHA-256 Hashes for Content Security Policy

Content Security Policy (CSP) blocks inline scripts by default — and that is exactly the point. But if you have legitimate inline scripts you cannot move to an external file, CSP gives you a way to whitelist them by their SHA-256 hash. Paste the inline script into a hash generator, copy the base64-encoded SHA-256, and put it in your Content-Security-Policy header. The browser will compute the same hash at load time and allow only the scripts that match.

This is the correct alternative to writing unsafe-inline in your CSP, which defeats the purpose of having a policy at all. Here is exactly how to do it.

Why Content Security Policy Rejects Inline Scripts

CSP was designed to prevent cross-site scripting (XSS) attacks. When an attacker injects malicious JavaScript into your page, the browser cannot tell the difference between your code and theirs — both are inline. CSP solves this by refusing to run any inline script unless you explicitly authorize it.

The weak workaround is adding unsafe-inline to your script-src directive. This tells the browser "run any inline script, including injected ones" — it completely disables XSS protection for inline code. Google's web.dev team estimates that over 95% of real-world CSP policies are bypassed because they include unsafe-inline.

The right approach is hash-based allowlisting. Instead of allowing all inline scripts, you provide the SHA-256 hash of each specific script you trust. The browser computes the same hash and only runs scripts whose hash matches. An injected script will not match, so it will not run.

How to Generate a SHA-256 Hash for Your Inline Script

The process takes under a minute. Open the Hash Generator, paste your inline script content into the text field (without the script tags — just the code inside them), click SHA-256, and copy the result.

CSP expects the hash in base64 format, not hex. The Web Crypto API used by this tool outputs hex by default. To convert to the base64 format CSP needs, you can use the Base64 Encoder — paste the raw bytes, or use the browser console: btoa(String.fromCharCode(...new Uint8Array(hashBuffer))).

Many developers use the simpler approach: generate the hash with OpenSSL from the command line and have it output base64 directly. For quick testing and verifying hashes, the browser-based tool is faster. Here is what the final CSP directive looks like:

Content-Security-Policy: script-src 'sha256-abc123base64encodedHash==';

Each inline script gets its own hash entry. If you have three inline scripts, you list three sha256 values. If the script changes even by one character, the hash changes and the script will be blocked.

Sell Custom Apparel — We Handle Printing & Free Shipping

Step-by-Step: Add SHA-256 Hashes to Your CSP Header

1. Identify all inline scripts on your page. Open DevTools, go to Sources, and look for any code in script tags with no src attribute.
2. Copy the script content — everything between the opening and closing script tags, without the tags themselves.
3. Open the Hash Generator and paste the script content. Click SHA-256.
4. Convert the hex output to base64. The CSP spec requires the base64-encoded SHA-256 hash.
5. Add the hash to your CSP header: script-src 'sha256-BASE64HASH';
6. Test it. Load the page and check the browser console for CSP violations. Each blocked script reports its expected hash, so you can quickly add any you missed.
7. Repeat for inline styles if you also want to remove unsafe-inline from your style-src.

Pro tip: Chrome DevTools will show you the exact hash string it expected in the console error message. This makes it easy to catch any scripts you missed and add them to the policy.

Hash-Based CSP vs Nonce-Based CSP — Which Should You Use?

Hash-based and nonce-based CSP both achieve the same goal — eliminating unsafe-inline — but they work differently. Understanding when to use each helps you pick the right approach for your application.

Approach	How It Works	Best For
Hash-based	You compute the SHA-256 of each inline script once and add it to the header	Static sites, scripts that never change
Nonce-based	Server generates a random nonce per request; scripts carry the matching nonce attribute	Dynamic apps with server-rendered HTML
External scripts only	Move all code to .js files, remove all inline scripts	The cleanest long-term approach

Hash-based CSP is ideal for static sites, marketing pages, and anywhere your inline code does not change often. If your inline scripts are generated dynamically on each request, nonces are easier to maintain. Either way, you eliminate unsafe-inline and get real XSS protection.

Common Mistakes When Implementing Hash-Based CSP

The most frequent issue is whitespace. The hash covers the exact bytes of your script, including any leading or trailing whitespace. If your code minifier trims whitespace in production but not in development, the hash will not match. Always generate the hash from the exact bytes the browser will see in production.

The second common mistake is including the script tags in the hash. You hash only the content between the tags, not the tags themselves. A hash of <script>alert(1)</script> will fail; a hash of alert(1) is correct.

Third: encoding issues. The browser hashes the script as UTF-8. If your page uses a different charset or your tool encodes differently, the hash will not match. The Hash Generator uses the browser's native Web Crypto API with UTF-8 encoding, which matches what browsers compute during policy enforcement.

Frequently Asked Questions

Can I use SHA-1 or SHA-512 for CSP hashes?

CSP Level 2 and above supports sha256, sha384, and sha512. SHA-1 is not supported — browsers will reject it. SHA-256 is the most widely used and sufficient for all current use cases. Use sha256-HASH in your directive.

Does CSP hash work for inline styles too?

Yes. The same approach works for the style-src directive. Hash the content of your inline style block (without the style tags) and add sha256-HASH to style-src. This removes the need for unsafe-inline in styles as well.

What if my inline script changes frequently?

If your inline script changes on every request (for example, it includes a CSRF token or dynamic data), hash-based CSP becomes impractical. Use nonce-based CSP instead — the server generates a random nonce per request and adds it to both the CSP header and the script tag attribute.

How do I find all inline scripts to hash?

Open Chrome DevTools, go to the Console, and temporarily add a CSP meta tag with a strict policy. Every violation will log the hash the browser expected for that script. Collect all the hashes from the console and add them to your policy.