Introduction
When you load a script or stylesheet from a CDN, you trust that the CDN will serve the same file every time. But what if the CDN is compromised? An attacker could replace the JavaScript with malware that steals user data, and your page would load it without question. Subresource Integrity (SRI) solves this by letting you specify a cryptographic hash of the expected file. The browser verifies the hash before executing the script. If the file has been tampered with, the browser refuses to load it. This tool generates SRI hashes using SHA-256, SHA-384, or SHA-512 via the Web Crypto API.
What this tool does
- Generates SRI integrity hashes using SHA-256, SHA-384, or SHA-512 via crypto.subtle.digest.
- Output is formatted as the integrity attribute value: algorithm-base64hash.
- Paste any script or CSS content to get its hash instantly.
- Shows a ready-to-use script or link tag with the integrity and crossorigin attributes.
- All hashing happens client-side. Your code never leaves the browser.
How this tool works
The generator uses the Web Crypto API's crypto.subtle.digest function to compute a hash of the input text. It supports SHA-256, SHA-384, and SHA-512, which are the three algorithms allowed by the SRI specification. The hash is computed as a binary digest, then Base64-encoded. The output string follows the format specified in RFC 6920: the algorithm name, a hyphen, and the Base64-encoded hash. You paste this string into the integrity attribute of a script or link tag. The browser recomputes the hash when loading the resource and compares it to the integrity attribute. If they match, the resource executes. If not, the browser blocks it.
How Subresource Integrity works
Subresource Integrity was standardized by the W3C in 2016 as a way to verify that resources loaded from third-party servers have not been tampered with. It is specified in the W3C SRI specification.
How SRI works:
1. You compute a hash of the resource (JavaScript file, CSS file) using SHA-256, SHA-384, or SHA-512. 2. You Base64-encode the hash and prefix it with the algorithm name: `sha384-Base64HashHere`. 3. You add this string to the `integrity` attribute of a ` ```
Which algorithm to choose?
| Algorithm | Output size | Use case | |---|---|---| | SHA-256 | 32 bytes | Fast, sufficient for most use cases | | SHA-384 | 48 bytes | Default for most CDN-provided SRI hashes | | SHA-512 | 64 bytes | Maximum security, longer hash string |
The W3C specification requires at least one of SHA-256, SHA-384, or SHA-512. You can include multiple hashes in the integrity attribute separated by spaces, and the browser will accept the resource if any one matches. This is useful when migrating between algorithms.
How to use this tool
- Paste the contents of your JavaScript or CSS file into the input field.
- Select the hash algorithm (SHA-384 is the most common default).
- Copy the integrity hash from the output panel.
- Add the integrity attribute and crossorigin="anonymous" to your script or link tag.
- Test in a browser to verify the resource loads correctly.
Real-world examples
Securing a CDN-hosted jQuery
A developer loads jQuery from a public CDN. They download the jQuery source, paste it into the SRI generator, and get the integrity hash. They add it to their script tag: ``. If the CDN is compromised and serves a modified jQuery, the browser blocks it and the page falls back to a local copy.
Verifying a third-party analytics script
A security engineer audits their company's website, which loads a third-party analytics script from an external domain. They fetch the current script content, generate an SRI hash, and add it to the script tag. Now if the analytics vendor is compromised and serves a malicious script, the browser will block it. They schedule quarterly reviews to update the hash when the analytics script is legitimately updated.
Generating hashes for a build pipeline
A DevOps engineer automates SRI hash generation in their CI/CD pipeline. They use this tool during development to verify the hash format, then implement the same logic in their build script using Node.js crypto. The build script computes SHA-384 hashes for each bundled JavaScript file and injects them into the HTML template's script tags automatically.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| SRI with SHA-384 | Low | Standard CDN script verification |
| SRI with SHA-256 | Low | Faster hashing, shorter hash string |
| Self-hosting resources | Medium | Full control, no CDN dependency |
| CSP with nonce | High | Dynamic script verification per request |
Limitations or considerations
SRI only protects against tampering of the resource content. It does not protect against a compromised CDN that serves a valid but malicious resource with a matching hash (the attacker would need to know the hash in advance, which requires compromising your build pipeline). SRI does not work for resources loaded via XMLHttpRequest or fetch; it only applies to script and link elements. If you update the resource, you must update the integrity hash. Some older browsers (Internet Explorer, Safari before version 11) do not support SRI and will load the resource without verification.
Frequently asked questions
Which algorithm should I use?
SHA-384 is the most common choice and is used by most CDN providers. SHA-256 is faster and produces a shorter hash. SHA-512 provides maximum security but has a longer hash string.
Do I need crossorigin="anonymous"?
Yes. SRI requires CORS to work. Without crossorigin="anonymous", the browser cannot read the resource to verify the hash, and the integrity check is skipped.
Can I use SRI with same-origin resources?
Yes, but it is unnecessary. SRI is designed for cross-origin resources loaded from CDNs. Same-origin resources are already under your control.
What happens if the hash does not match?
The browser blocks the resource and fires an error event. You can listen for this event and provide a fallback, such as loading a local copy of the script.
Can I specify multiple hashes?
Yes. Separate them with spaces in the integrity attribute. The browser accepts the resource if any hash matches. This is useful when migrating between algorithms.
Conclusion
SRI is a simple, high-impact security measure for any page that loads scripts or stylesheets from CDNs. Use this tool to generate integrity hashes during development, then automate the process in your build pipeline. For broader content security, combine SRI with a Content Security Policy. To generate secure random tokens for nonces, try the NanoID Generator.