Subresource Integrity (SRI) Checker & Hash Generator

Report

Common questions

What is Subresource Integrity and why does it matter?

Subresource Integrity (SRI) lets a page declare the exact cryptographic hash a script or stylesheet must have before the browser will run or apply it. Without it, a page that loads a library from a third-party CDN is trusting that CDN completely: if the CDN is compromised, misconfigured, or silently changes what it serves, every site loading that file runs whatever it now contains. An integrity attribute turns that silent trust into a check the browser enforces itself.

Why do I need a CLI instead of just checking a URL I type into the page?

Reading another site's response body from browser JavaScript is restricted by CORS, and most pages you would want to check do not opt a script into letting your tab read their full HTML. The CLI has no such restriction — it fetches the page and each cross-origin asset directly, the same way curl or any other HTTP client would, then hands the browser page a JSON report to render. The hash generator above does not have this limitation: it hashes content you paste in, with no fetch involved at all.

Why does an integrity attribute need a crossorigin attribute too?

Per the Fetch spec, a cross-origin request has to opt into CORS mode before the browser is allowed to read enough about the response to verify a hash against it. A crossorigin attribute is what makes that opt-in. Without it, most browsers silently skip the integrity check on a cross-origin tag rather than enforcing it — which is worse than having no integrity attribute at all, because the page looks protected and is not.

What does a hash mismatch finding actually mean?

It means the file this tool just fetched from the declared URL does not match the hash written into the page's integrity attribute. Either the CDN-served file has changed since the tag was written — in which case browsers will now refuse to load it at all, breaking the page for every visitor — or the hash was wrong from the moment it was added. Either way, the fix is to regenerate the hash from the file as it exists right now.

Does a clean report mean the page has no supply-chain risk?

No. This checks one specific, well-documented protection — integrity hashes on cross-origin script and stylesheet tags — not a full security assessment. It does not evaluate same-origin code, inline scripts, iframes, images, fonts, or any other resource type, and it cannot see a risk outside that scope. Treat a clean report as evidence about this one protection, not a determination that the page is secure.

More background: why an integrity attribute with no crossorigin attribute leaves a page unprotected, how this tool compares to srihash.org, or why checking a page's tags by hand misses the two failures that matter most.