Subresource Integrity generator & verifier
Paste the exact bytes of a script or stylesheet (or drop the file) and get the integrity attribute to put on your <script> or <link>. Paste an existing integrity value too and this checks it against those bytes, names the hash the browser actually enforces, and tells you why it would fail. The hashing runs in your browser with the Web Crypto API; nothing is uploaded.
Accepts a bare sha384-..., a space-separated list of hashes, or the whole integrity="..." attribute pasted in.
hashing…
What the integrity attribute is
Subresource Integrity lets the browser refuse to run a script or apply a stylesheet whose bytes do not match a hash you pinned in the HTML. You add integrity="sha384-…" to the <script> or <link rel="stylesheet"> tag; the browser downloads the file, hashes it, and compares. A mismatch blocks the resource entirely, the same as a network error. The hash is a base64 encoding of the raw digest, prefixed by the algorithm name and a dash.
The browser enforces the strongest hash you list
You may list several hashes separated by spaces, for example sha256-… sha384-…. The browser does not require all of them to match. It picks the strongest algorithm it understands from your list (sha512 over sha384 over sha256) and validates against only the entries for that one algorithm; if you list two hashes of the same strongest algorithm, any one matching is enough. The trap: if you add a stronger hash that is wrong, the browser ignores your correct weaker one and blocks the file. This tool tells you exactly which algorithm is being enforced and what the bytes actually hash to.
Cross-origin needs crossorigin, or SRI does nothing
For a resource served from a different origin, integrity is only enforced when the request is made with CORS, which for a tag means adding crossorigin="anonymous". Without it the browser fetches the file as an opaque no-cors response whose bytes it is not allowed to read, so it cannot hash them and the integrity attribute is silently ignored. A same-origin resource does not need crossorigin. The other quiet rule: SRI applies to <script>, <link rel="stylesheet">, and module/preload variants. It does nothing on images, iframes, or fetch unless you wire it up in code.
Hash the file you actually ship
The hash is over the exact transferred bytes. Minify, bundle, or re-save with a different line ending and the digest changes, so generate the integrity from the built file, not the source. sha1 and md5 are not accepted by the spec and are ignored by browsers; only sha256, sha384, and sha512 are valid. sha384 is the common default.
What this tool does not do
It does not fetch the resource for you, so it cannot tell whether your real CDN serves these exact bytes or sends the right CORS headers; paste or drop the file you deploy. It hashes whatever you give it, treating the textarea as UTF-8 (a dropped file is hashed byte for byte). It reasons about the integrity string and the bytes in front of it, not the surrounding page or the network.
Attribute reference
| token | meaning |
|---|---|
| sha384-… | Algorithm name, a dash, then base64 of the raw digest. Valid algorithms are sha256, sha384, sha512. |
| space-separated | Multiple hashes in one attribute. The browser enforces only the strongest algorithm present; same-algorithm entries are an OR. |
| crossorigin | Set to anonymous (or use-credentials) so a cross-origin fetch is CORS-enabled and the bytes are readable. Without it SRI is not enforced on cross-origin resources. |
| base64 length | sha256 is 44 chars, sha384 is 64, sha512 is 88 (all including = padding). A wrong length means a corrupt or truncated hash. |
Single static HTML file, no network. The bytes you paste or drop never leave the browser. Source: github.com/truffle-dev/tool-sri. MIT.