SRI Hash Generator & Integrity Policy Helper
Generate Subresource Integrity hashes for JS and CSS assets, build exact integrity tags, and create Integrity-Policy headers with reporting support.
Local file and paste modes hash entirely in your browser using the Web Crypto API — no content is uploaded. Remote URL mode uses a transient server-side fetch to bypass CORS restrictions; the asset bytes are not logged or stored.
Algorithm
SHA-384 is the recommended default for SRI
crossorigin attribute
Use anonymous for most cross-origin CDN assets
Asset is fetched via a transient server-side helper to bypass CORS. The content is not logged or stored.
Integrity-Policy Header Builder
Generate Integrity-Policy and Reporting-Endpoints headers for progressive hardening
Local file and paste modes hash entirely in your browser using the Web Crypto API — no file content is uploaded to any server. Remote URL mode uses a transient server-side fetch to bypass CORS restrictions; fetched asset bytes are not logged, cached, or stored by CodeAva. This tool generates integrity hashes for verification purposes only and does not modify, re-host, or intercept any third-party assets.
Overview
Every third-party JavaScript or CSS file your site loads from a CDN is a point of supply-chain trust. If that file changes — through a CDN compromise, a build pipeline error, or an upstream maintainer update — your users' browsers will silently load whatever byte sequence the CDN returns. Subresource Integrity (SRI) addresses this by letting you pin the exact expected content of a fetched asset as a cryptographic hash in your HTML. If the file changes by even a single byte, the browser refuses to execute the script or apply the stylesheet.
Despite being a W3C standard with broad browser support since 2016, SRI adoption remains lower than it should be. The most common friction point is tooling: generating a correct SHA-384 hash from a CDN URL on the command line involves curl, openssl, and base64, and the output must be prefixed exactly right. This tool removes that friction with three input modes, sensible defaults, and copy-ready output for both script and stylesheet tags.
For teams ready to go beyond per-tag SRI, the Integrity-Policy header offers a browser-level policy that reports or blocks any covered resource loaded without a valid integrity attribute. Like CSP, starting in report-only mode and reviewing violations before enforcing is the recommended approach. Browser support is newer and should be treated as progressive hardening rather than a universally enforced baseline.
Use cases
When to use it
- Generating SRI hashes for CDN-hosted JS and CSSpaste any public CDN URL — the tool fetches the asset via a transient edge helper to bypass CORS, hashes the bytes, and returns the integrity string and ready-to-paste HTML tags.
- Hashing local build artifacts before deploymentupload a .js or .css file from disk. The file is hashed entirely in the browser using Web Crypto — no upload occurs. Useful for verifying hash values against what your build pipeline should generate.
- Pasting content to verify a hash manuallypaste raw JavaScript or CSS text for instant in-browser hashing. Useful for debugging hash mismatches by comparing content against an expected integrity value.
- Generating production-ready HTML integrity tagsget copy-ready <script> and <link rel=stylesheet> tags with the correct integrity attribute, crossorigin attribute, and format.
- Building an Integrity-Policy header with reportingconfigure blocked destinations, choose report-only or enforce mode, set a Reporting-Endpoints URL, and get copy-ready server configuration for Nginx, Apache, Vercel, Next.js, and Cloudflare.
- Understanding crossorigin CORS requirements for SRISRI on cross-origin assets requires both crossorigin=anonymous on the tag AND the server returning appropriate CORS headers. The tool warns when this combination may not be satisfied.
When it's not enough
- Using SRI on assets that change without a URL changeif a CDN URL like /latest/script.js can serve different content over time, SRI will cause the resource to fail after any update because the hash will no longer match. Pin to versioned URLs or content-hashed filenames.
- Treating SRI as a CSP replacementSRI verifies that a specific fetched resource matches an expected hash. CSP controls which origins may serve resources at all. They serve different and complementary roles — neither replaces the other.
- Deploying Integrity-Policy enforce mode without testingwithout first running in report-only mode and reviewing violations, enforce mode may block legitimate resources and cause page breakage for users. Always start with report-only.
How to use it
- 1
Choose URL, file upload, or paste mode
Remote URL fetches the asset via an edge helper to bypass CORS. Local File hashes in your browser without any upload. Paste Content hashes raw text instantly in the browser.
- 2
Select SHA-256, SHA-384, or SHA-512
SHA-384 is the recommended default for SRI and is used by most published CDN integrity values. SHA-512 provides a larger hash. SHA-256 is supported but produces a shorter output.
- 3
Copy the generated tag or integrity value
Use the HTML Tags tab for copy-ready <script> or <link> tags. Use the Integrity Value tab for the bare sha384-... string to paste into an existing tag.
- 4
Review warnings and crossorigin guidance
The Warnings tab flags versionless URLs, cross-origin CORS requirements, and asset-type ambiguity. Address these before deploying tags to production.
- 5
Build an Integrity-Policy header in report-only mode
Open the Integrity-Policy builder. Start with report-only, select script and/or style destinations, add a reporting endpoint URL, and copy the headers for deployment.
- 6
Switch to enforce mode after reviewing violation reports
Once you've confirmed all covered assets have correct and current integrity attributes, switch to Integrity-Policy enforce mode for active browser-level blocking.
Common errors and fixes
SRI hash mismatch in production
The most common cause is the CDN serving a different byte sequence than when you generated the hash — minification changes, gzip transformation issues, or a CDN updating the file. Regenerate the hash from the live URL and update the integrity attribute. Consider pinning to a specific version URL rather than a floating /latest/ path.
Forgetting crossorigin=anonymous on cross-origin assets
SRI requires the browser to inspect the full response body, which is only allowed for CORS-enabled requests. Without crossorigin=anonymous on the tag, the browser uses a no-cors request for cross-origin assets and cannot compare the hash. Add crossorigin=anonymous AND ensure the CDN returns an Access-Control-Allow-Origin header.
Using SRI on assets transformed by CDN optimization
Some CDNs rewrite or compress assets on the fly after delivery. If the CDN modifies the bytes between your hash generation and the browser request, SRI will fail. Use a CDN configuration that serves assets without transformation, or test by fetching the exact URL the browser will use.
Assuming CSP and SRI solve the same problem
CSP controls which origins may serve scripts and styles. SRI verifies the exact content of a specific file. A script allowed by CSP can still be harmful if its content was tampered with — SRI guards against that. A file with the correct SRI hash can still come from a blocked origin under CSP. Both layers are needed for comprehensive script supply-chain protection.
Protecting scripts but forgetting stylesheets
CSS can exfiltrate data via attribute selectors and can modify page layout in security-sensitive ways. Apply SRI to both script and link tags for third-party assets, and configure Integrity-Policy to cover both script and style destinations.
Using versionless third-party URLs
URLs like /v1/script.js or /latest/style.css can serve different content after upstream updates, breaking SRI silently (the hash no longer matches). Always pin to a specific version (e.g. /v1.2.3/script.js) and update deliberately when upgrading the dependency.
Deploying Integrity-Policy enforce without a reporting endpoint
Without Reporting-Endpoints configured, violations are silent — you have no visibility into what resources would be blocked. Configure a reporting endpoint, deploy in report-only mode first, review violations, fix all integrity attribute gaps, then switch to enforce mode.
Frequently asked questions
Related
What is Subresource Integrity (SRI)?
Subresource Integrity (SRI) is a W3C browser security feature that lets you verify that a fetched JavaScript or CSS file exactly matches a cryptographic hash you provided in the HTML tag. You add an integrity attribute to a <script> or <link> tag containing the expected hash. When the browser fetches the resource, it computes the hash of the received bytes and compares it to the expected value. If they do not match — because the file was modified, replaced, or tampered with — the browser refuses to execute the script or apply the stylesheet.
SRI reduces supply-chain risk from third-party CDN assets. It does not prevent the request from being made, and it does not protect against all CDN compromise scenarios (for example, if an attacker can also modify your HTML). SRI is most effective when paired with a Content Security Policy that restricts which origins may serve scripts and styles.
Why SRI matters for CDN supply-chain risk
When you load a third-party library from a CDN without SRI, your users' browsers trust whatever bytes the CDN returns at that URL. If the CDN is compromised, if a popular package is updated to include malicious code, or if a build pipeline error pushes a bad artifact, your site silently serves the modified code to every user who loads the page.
With SRI, any modification to the asset causes an immediate browser-level integrity failure. The resource is blocked before execution. Users are not exposed to the modified code. Your monitoring sees the failure. This is meaningfully stronger than relying solely on CDN provider security promises.
SRI vs Content Security Policy (CSP)
| Feature | CSP | SRI |
|---|---|---|
| Purpose | Controls which origins may serve scripts, styles, and other resources | Verifies that a specific fetched resource matches an expected hash |
| Trust model | Origin-based — trust domains or URLs | Content-based — trust exact byte sequences |
| Granularity | Policy applies to all matching requests | Applied per resource tag via the integrity attribute |
| Best for | Preventing resources from unknown or untrusted origins | Detecting modifications to known, trusted third-party files |
| Example | script-src 'self' https://cdn.example.com | <script src="..." integrity="sha384-..."> |
| Limitation | Does not verify file content — a trusted origin can still serve bad files | Does not prevent the request — a tampered file is blocked after fetch, not before |
CSP and SRI are complementary controls. CSP restricts the origin; SRI verifies the content. Both together provide meaningful script supply-chain protection.
Integrity-Policy explained
Integrity-Policy is a response header that instructs browsers to require a valid integrity attribute on all resources matching the configured destinations. Without it, SRI is opt-in per tag — a developer could forget to add integrity to a new script tag and no one would notice. With Integrity-Policy, the browser enforces the requirement at a policy level.
- Integrity-Policy-Report-Only — reports violations to your reporting endpoint but does not block resources. Start here.
- Integrity-Policy — blocks covered resources that lack a valid integrity attribute. Switch here once violations are resolved.
- Reporting-Endpoints — configures where violation reports are sent. Required for useful visibility before enforcement.
- Browser support — newer than SRI and not universal. Treat as progressive hardening, not a reliable baseline across all browsers today.
Generating SRI hashes from the command line
# SHA-384 (recommended) — OpenSSL
cat file.js | openssl dgst -sha384 -binary | openssl base64 -A
# → prefix the output with "sha384-"
# SHA-384 — shasum + xxd + base64 (macOS / Linux)
shasum -b -a 384 file.js | awk '{ print $1 }' | xxd -r -p | base64
# SHA-256
cat file.js | openssl dgst -sha256 -binary | openssl base64 -A
# SHA-512
cat file.js | openssl dgst -sha512 -binary | openssl base64 -A- Prefix the base64 output with
sha384-(orsha256-/sha512-) to form theintegrityattribute value. - Any byte change — including whitespace, newlines, or encoding differences — produces a completely different hash.
- CI/CD pipelines can regenerate hashes automatically when vendor files change; treat integrity values as build artifacts alongside the asset URLs they reference.