SRI Hash Calculator
Generate Subresource Integrity hashes for third-party scripts and styles.
We fetch the file in your browser and compute its SRI hash locally.
Understanding Subresource Integrity (SRI)
SRI is the browser's built-in shield for third-party dependencies: it blocks modified files before they can run.
The shield for your dependencies
Modern sites rely on CDNs for libraries like React, Bootstrap, or jQuery. That convenience comes with supply‑chain risk: if a CDN (or any upstream) is compromised, attackers can inject malicious code. SRI lets the browser detect unexpected changes and block the file before it executes.
How SRI works
SRI follows a “trust but verify” model.
- Fetch the file from the URL
- Hash the downloaded bytes locally in the browser
- Match against your integrity value
If even a single byte differs (hacking, re-minification, compression differences, corruption), the hashes won’t match and the browser refuses to execute the script or apply the stylesheet.
How to use SRI
Generate an integrity value
- Paste the asset URL (JS or CSS) into the calculator above
- Pick an algorithm (SHA-256 is a great default)
- Copy the generated value (or the full snippet)
- Set integrity to the computed hash
- Include crossorigin="anonymous" for cross‑origin assets
For JavaScript
<script
src="https://cdn.example.com/library.js"
integrity="sha384-Li9WySrDBqasd...your-hash..."
crossorigin="anonymous">
</script>For CSS
<link
rel="stylesheet"
href="https://cdn.example.com/style.css"
integrity="sha384-Li9WySrDBqasd...your-hash..."
crossorigin="anonymous"
/>Algorithms & CORS
Choosing an algorithm
| Algorithm | Performance | Security level | Recommendation |
|---|---|---|---|
| SHA-256 | Fastest | High | Good default; fine for most cases. |
| SHA-384 | Balanced | Very high | Industry standard; recommended for most sites. |
| SHA-512 | Slower | Extreme | Great for higher-security environments. |
The `crossorigin` requirement
- crossorigin="anonymous": fetches without cookies (standard for most CDNs)
- The CDN should send Access-Control-Allow-Origin so the browser can perform the integrity check.
- If you add integrity but omit crossorigin on a cross‑origin resource, the browser will block the resource because it cannot verify the integrity hash against an opaque response.
Why do I need to include crossorigin="anonymous"?
For scripts/styles loaded from a different origin, the browser needs an explicit CORS mode to safely fetch the bytes and enforce the SRI check. If you omit crossorigin, the browser fetches the resource in no-cors mode, which makes the response opaque. Since the browser cannot verify the integrity hash against an opaque response, the resource is blocked.
- crossorigin="anonymous" sends no cookies or credentials (but it does send an Origin header).
- The CDN must allow the browser to use the response by returning Access-Control-Allow-Origin. If it doesn’t, the browser will block the resource.
When to use SRI and when not to
Good fit
- Third-party CDN assets you don't control
- Versioned URLs (e.g. v1.2.3/main.js)
- Popular libraries + CSS frameworks served via CDN
Not a great fit
- “Latest” URLs that change automatically
- Dynamic endpoints (user/session-specific responses)
- Assets you fully control (often better to rely on deploy integrity + CSP)
Pros and trade-offs
Benefits
- Blocks tampered CDN files before they run
- Reduces third‑party supply‑chain risk
- Encourages pinning to tested versions
Trade-offs
- Any byte change breaks the hash
- Updates require regenerating integrity (by design)
Want to harden third‑party scripts even more?
Pair SRI with a strict Content Security Policy, continuous monitoring and script inventory.