Subresource Integrity Generator
Generate SRI hashes for JavaScript and CSS assets in your browser — paste code, fetch from a URL or drop a file — and get copy-ready integrity attributes, script/link tags, and verification of existing hashes.
Subresource Integrity (SRI) is the W3C standard that stops a compromised CDN from silently serving you malicious code: you publish a cryptographic hash next to each <script> or <link> tag, and the browser refuses the asset if even one byte differs. This generator computes all three SRI digests (SHA-256, SHA-384, SHA-512) with your browser’s built-in Web Crypto API, builds the exact HTML you need to paste into your page, and can verify an existing integrity value against the asset it claims to protect.
Generate SRI hashes
Hashing is done on the exact text you paste — one extra newline or a re-save with different line endings changes every digest. When in doubt, use From URL so this page fetches the same bytes your visitors’ browsers will download.
This page fetches the URL directly from your browser and hashes the exact bytes served — the most reliable way to pin a CDN asset. Major CDNs (jsDelivr, cdnjs, unpkg, Google Fonts) allow cross-origin reads; if the host blocks them you’ll see a clear message and can fall back to pasting the code.
The file is read locally with the File API and never uploaded.
Tip: press Ctrl+Enter in the code box to generate.
Overview
| Source | |
|---|---|
| Size | |
| Lines |
SRI hashes
All three digests the SRI standard allows. Use SHA-384 for new deployments (strong, supported by every current browser); SHA-256 if you must support older browsers.
Ready-to-paste HTML
Verify an existing integrity value
Paste the integrity attribute you already ship (one or more space-separated values) and check it against the hashes computed above. This is the “did my CDN asset change — or was it tampered with?” check.
How Subresource Integrity works
SRI adds a hash of the asset’s exact bytes to the tag that loads it:
When the browser loads the page, four things happen in order:
- Fetch. The browser downloads the asset over HTTPS. Because of crossorigin="anonymous", it does so in CORS mode (more on that below).
- Digest. It computes the cryptographic hash of the exact bytes received, for every algorithm named in the integrity attribute — SHA-256, SHA-384 and/or SHA-512.
- Compare. If any computed digest matches one of the listed values, the check passes. The script runs or the stylesheet applies, exactly as if SRI were not there.
- Block on mismatch. If no digest matches, the browser refuses to execute or apply the resource and logs an error in the console (“The resource ... required an integrity check... but the request was made without one” / SRI hash mismatch). The rest of your page keeps working — that one asset simply never runs.
The key property: you trust the bytes, not the server. It does not matter who served the file — a compromised CDN, a hijacked DNS entry, a rogue cache node. If the bytes differ from what you pinned, nothing executes.
Why it matters: the CDN supply chain
Most sites load jQuery, Bootstrap, analytics and fonts from third-party CDNs. That is a dependency you cannot audit — if the CDN’s account, origin server or build pipeline is compromised, every site that loads from it can be silently compromised at once, with no code change on your side.
The canonical incident: in 2015 a compromised cdnjs.com account could have served malicious “jQuery” to roughly 1.6 million sites. SRI is the fix for exactly this class of attack — even if an attacker controls the CDN and serves altered bytes, every site that pinned a hash simply refuses them.
SRI is also defense in depth on top of HTTPS: TLS protects the bytes in transit between you and the server, but it cannot stop a server that has been turned against you. SRI pins the content itself.
The crossorigin="anonymous" requirement
A cross-origin resource loaded without a crossorigin attribute arrives as an “opaque response” — the browser deliberately hides its contents from scripts, and it cannot verify such a response against an integrity hash. So SRI effectively requires:
- crossorigin="anonymous" on the tag (the request is made in CORS mode, no credentials sent), and
- a CDN that answers with an Access-Control-Allow-Origin header. All major CDNs (jsDelivr, cdnjs, unpkg, Google Fonts, Cloudflare) do.
If you see SRI errors in the console for a resource that “should” pass, a missing crossorigin attribute or a CDN without CORS headers is the usual cause.
Multiple hashes and key rotation
The integrity attribute accepts any number of space-separated values, and the check passes if any one of them matches. Two practical uses:
- Algorithm flexibility. Publish sha384-... sha512-... so different browser builds (which may implement different algorithm sets) all find a match.
- Rotation without downtime. When an asset is updated and you have a new hash, temporarily publish both the old and the new value. Visitors on cached pages still validate against the old hash; fresh loads validate against the new one. Remove the stale value after your cache TTL has passed.
The “Copy all three” button above gives you exactly this combined attribute in one click.
Limitations to know
- HTTPS only. The integrity attribute is ignored for resources loaded over plain HTTP — SRI cannot protect a channel that isn’t encrypted in the first place. Serve (and load) everything over HTTPS.
- CDN must allow CORS. As above, the origin has to send Access-Control-Allow-Origin.
- No protection for inline code. Inline <script>/<style> blocks are part of your own HTML — there is no separate fetch to pin. Content Security Policy is the tool for that layer.
- Older browsers ignore it. Browsers without SRI support (IE11 and earlier) simply drop the unknown attribute and load the resource normally — no breakage, just no protection on those clients.
- Your own origin is your responsibility. SRI shines for third-party CDNs. If you self-host, a compromised server can change both the asset and any hash you generate from it — pinning hashes of your own files mostly guards against accidental deploys and cache poisoning.
Generating SRI hashes on the command line
If you’d rather pin hashes in a build step than by hand, OpenSSL does it in one line (note the standard Base64 encoding, no line wrapping):
The same idea works for CSS, and with -sha256 / -sha512 for the other digests. Whatever you generate, verify it against what the CDN actually serves — a minifier or re-upload that changes one byte invalidates every hash.
Suggested
