SRI Hash Generator
Generate a Subresource Integrity hash for a script or stylesheet and copy a ready-made <script> or <link> tag — so the browser refuses the file if a CDN ever serves tampered bytes. SHA-256, 384 and 512, computed locally in your browser; nothing is uploaded.
New to this? Read the SRI Hash Generator guide →
Drag a file here, or to hash it.
The file is read and hashed in your browser — it is never uploaded.
Paste content or choose a file to generate an integrity hash.
Everything runs locally in your browser — the file or text you hash is never uploaded.
How to use the SRI generator
Give it the exact bytes your users will download: drag in the built file (the minified lib.min.js you’ll actually reference, not the source), or paste its contents. Pick an algorithm — SHA-384 is the usual choice — and a resource type, optionally paste the public URL, and copy the ready-made <script> or <link> tag. The integrity attribute pins that file: if a single byte differs when the browser fetches it, the browser refuses to run it.
Match the hash to the served file exactly
SRI compares the hash of what the browser received to the one you published, so they must be byte-identical. The two things that trip people up: hashing the un-minified source when the page loads the minified build, and a CDN that re-minifies or re-compresses on the fly so the delivered bytes differ from your local copy. Always hash the precise artifact at the precise URL you’ll ship. If a library offers Brotli and gzip variants, note that SRI checks the decoded bytes, so transport compression is fine — but a CDN transform that changes the actual content is not.
Why crossorigin="anonymous" is required
For a resource loaded from another origin (any CDN), the browser will only run the integrity check if the response is CORS-eligible — otherwise it can’t safely read the bytes to hash them. That’s why the snippet includes crossorigin="anonymous": it makes the request without credentials and tells the browser to expect CORS headers. Reputable CDNs send them; if a resource doesn’t, SRI can’t protect it, and that’s worth knowing before you rely on it.
Which algorithm, and using several
SHA-384 is the common default — stronger than SHA-256 with no practical downside. You can also supply multiple hashes in one attribute separated by spaces (integrity="sha384-… sha512-…"); the browser uses the strongest it supports, which is handy during an algorithm transition. Avoid SHA-256-only for new work if you can, and never anything weaker — SRI explicitly requires a member of the SHA-2 family.
Frequently asked questions
What is a Subresource Integrity (SRI) hash?
A cryptographic hash of a script or stylesheet, placed in an integrity attribute, that lets the browser verify the file was not tampered with. If the fetched file does not match the hash, the browser refuses to run it — protecting your users if a CDN is compromised.
Which hash algorithm should I use?
SHA-384 is the common default; SHA-256 and SHA-512 are also valid. SRI requires a SHA-2 family algorithm — MD5 and SHA-1 are not allowed. You can include several hashes in one attribute and the browser uses the strongest it supports.
Why does the tag include crossorigin="anonymous"?
For a file loaded from another origin (any CDN), the browser only runs the integrity check when the response is CORS-eligible. crossorigin="anonymous" makes a credential-less request and expects CORS headers, without which the check cannot run.
Is my file uploaded?
No. The file or text is read and hashed entirely in your browser with the Web Crypto API — nothing is uploaded, so it works on internal or unpublished files too.