Subresource Integrity (SRI) lets browsers verify that external scripts and stylesheets have not been tampered with. Add an integrity attribute to your <script> or <link> tags and browsers will refuse to load altered files.
How to use SRI hashes
- 1Paste the URL of your CDN resource, your raw file contents, or upload the file.
- 2Select one or more hash algorithms. SHA-384 is recommended by the W3C specification.
- 3Click Generate and copy the ready-to-paste HTML snippet into your page.
- 4Regenerate whenever the resource file changes so the hash stays in sync.
What is a Subresource Integrity (SRI) hash generator?
A Subresource Integrity hash generator computes a cryptographic fingerprint of an external script or stylesheet and formats it as a base64-encoded hash ready to drop into an HTML integrity attribute. When a browser loads a resource tagged with an SRI hash, it re-computes the hash on the downloaded bytes and refuses to execute or apply the file if the hashes do not match. This one-line addition to a script or link tag is one of the most effective defences against supply-chain attacks, where a compromised CDN silently serves malicious code to every site that links to it.
Why SHA-384 is the recommended algorithm
The W3C SRI specification recommends SHA-384 as the best balance between security and performance. SHA-256 is faster but provides a shorter hash, while SHA-512 is marginally more resistant to theoretical collision attacks but adds bytes to every page request. Most tooling defaults to SHA-384, and browsers support all three. You can supply multiple algorithms separated by a space, letting browsers choose the strongest one they support.
URL fetch, paste, or upload: which should you use?
Fetching by URL is the most convenient option for public CDN resources because it downloads the exact bytes browsers will receive. Pasting raw content is useful when you are working with a local build before deployment and want to pre-compute the hash. Uploading a file gives you an identical result to pasting but avoids copying large minified bundles by hand. All three paths produce the same hash for the same content.
The crossorigin attribute is not optional
SRI enforcement requires the crossorigin attribute on the tag. Without it, browsers do not expose response bytes for verification on cross-origin fetches and the integrity check fails silently or is skipped entirely, leaving you with no protection. The generated snippets on this page always include crossorigin="anonymous" so the tag is safe to paste as-is.
Frequently asked questions
What is Subresource Integrity?
Subresource Integrity (SRI) is a W3C browser security feature that lets you attach a cryptographic hash to a script or stylesheet tag. The browser re-hashes the downloaded file and blocks it if the hash does not match, protecting your site against tampered CDN files.
Which hash algorithm should I use for SRI?
SHA-384 is the recommended choice. It is supported by all modern browsers, provides strong collision resistance, and is the default in tools like the official srihash.org generator. You can include multiple algorithms in one integrity attribute for broader compatibility.
Why does SRI need crossorigin="anonymous"?
Without crossorigin="anonymous", the browser treats the fetch as a no-CORS request and withholds the response bytes from JavaScript and from the SRI verification step. The integrity check only runs when the resource is fetched with CORS, which that attribute enables.
What happens if the CDN file changes after I set the hash?
The browser will block the resource entirely and log a console error. This is intentional: the mismatch signals that the file has changed, whether from a legitimate update or a supply-chain attack. Regenerate the hash whenever you intentionally upgrade to a new version of the library.
Can I use SRI for first-party scripts on my own domain?
Yes, though it is most valuable for cross-origin resources. For same-origin files the browser already trusts your server, so SRI is less critical. It can still be useful if your CDN or storage bucket is a separate origin from your HTML page.
Does this tool send my file contents to a server?
No. When you paste content or upload a file, all hashing runs entirely in your browser using the native Web Crypto API. Only URL fetches are proxied through the edge to handle CORS restrictions on third-party CDNs.