SRI hash calculator

What is a Subresource Integrity (SRI) hash?

An SRI hash is a base64-encoded SHA digest of the exact bytes of a file. You put it in the integrity attribute of a script or link tag; the browser hashes what it downloads, compares, and refuses the resource on any mismatch, treating it as a network error.

It defends against one specific threat: a third-party host or CDN that serves you tampered or compromised code. Because the value is tied to the exact file, an attacker who swaps the asset cannot make the browser run it. Read the full explanation in the Subresource Integrity guide.

<script
  src="https://cdn.example.com/app.min.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"></script>

Which resources can carry an SRI hash?

Only two: a script tag, and a link tag whose rel is stylesheet, preload or modulepreload. On an image, an iframe, a video or a font the attribute is ignored, with no warning.

It is worth adding wherever the file is supposed to stay exactly as it is today:

• A library pinned to a version on a public CDN
• A stylesheet or icon font served from another host
• A widget or SDK bundle at a URL that never changes
• Your own build output, where the bundler writes the hashes for you

Add the crossorigin attribute

For a file on another origin, add crossorigin="anonymous" next to integrity. A browser only verifies a cross-origin resource when the host allows the read with CORS, an Access-Control-Allow-Origin header. Without it the browser cannot check the file and ignores the integrity attribute, which is why this tool warns you when a URL is not CORS-readable.

The attribute pair is the same on both tags:

<script
  src="https://cdn.example.com/chart.min.js"
  integrity="sha384-Cbq7oAJVQfWCcGpuf3EmLpr4wqzBQKux9Hy8drVeoJXPFrWvNQ1kPzQho2wxJwY8"
  crossorigin="anonymous"></script>

<link
  rel="stylesheet"
  href="https://cdn.example.com/theme.css"
  integrity="sha384-VuArbKap7CY5uykM6oqf+R9GqQ8Kux9rx7HNQlGYl1kPzQho1wx4JwY8wCdgcRRap"
  crossorigin="anonymous">

Where SRI stops working

A hash covers one file at one URL, so it stops at the first thing that moves:

• Scripts that update at a fixed URL. A tag manager, an analytics loader or a payment SDK ships new bytes whenever the vendor decides, and a pinned hash blocks the page at the next release. Stripe.js is the clearest case: it must be loaded from js.stripe.com and accepts no hash at all.
• Scripts injected by another script. The hash you put on a loader covers the loader, not the tags it goes on to add, which is what makes tag managers hard to pin in practice.
• Files a cross-origin host will not serve with CORS. Without an Access-Control-Allow-Origin header the browser cannot read the file to check it, so it ignores the attribute.
• Inline scripts, and stylesheets pulled in by a CSS @import. Use a CSP hash for the first and pin the importing stylesheet for the second.

Requiring SRI across your site

SRI is opt-in: you add a hash tag by tag. The old CSP require-sri-for directive would have forced it site-wide, but it never shipped to a stable browser and is abandoned.

To require integrity across your whole site today, use the Integrity-Policy header: the browser blocks, or reports, any script loaded without valid SRI, turning a per-tag opt-in into an enforceable policy. Both are covered in the Integrity-Policy guide.

Integrity-Policy: blocked-destinations=(script)

SHA-256, SHA-384, or SHA-512?

SRI accepts the same three algorithms as CSP. SHA-384 is the most common choice for SRI, but all three are equally safe here, so pick one and apply it consistently. You can even list several hashes on one tag: the browser accepts the file if the strongest algorithm it understands matches.