SRI Hash Generator
Generate Subresource Integrity hashes for scripts and stylesheets so a compromised CDN can’t silently swap your code.
What this SRI hash generator does
Subresource Integrity lets a <script> or <link> tag declare exactly which bytes it expects. This tool computes that hash for you two ways: paste the file's content directly and it is hashed instantly in your browser with the Web Crypto API, or give it a script or stylesheet URL and the server fetches it and hashes the response. Either way you get the same output — the three algorithm variants and a tag ready to paste into your HTML.
Why SRI exists
When you load a script from a third-party CDN, you are trusting that CDN with full execution access to your page. If the CDN is compromised, or an attacker sits between your visitor and the CDN, the file that arrives can be different from the one you tested — and without SRI, the browser has no way to notice. A single injected line of JavaScript in a library your page trusts can read cookies, local storage, and anything the user types into your forms. SRI closes that gap: the browser hashes what it downloaded and compares it to the hash you shipped, and if they don't match, it refuses to run the file at all.
Choosing an algorithm
sha384 is the value this tool shows first and the one most SRI-aware ecosystems default to — it is what jQuery, Bootstrap and most CDN "copy tag" buttons publish. sha256 is faster to compute and still perfectly safe for this purpose; sha512 produces a longer, marginally stronger hash. Pick one — you do not need all three in production, though nothing stops you from listing more than one (see the FAQ below).
The classic mistake: hex instead of base64
The integrity attribute expects the hash encoded as base64, not hexadecimal. Run sha384sum on a file from a terminal and you will get a hex string — paste that straight into an integrity attribute and the browser will silently block the resource, because it never matches. This tool always encodes with base64, the same as crypto.subtle.digest() does when you convert its output correctly, and the same as every CDN's published SRI value.
Paste mode vs. URL mode
Paste mode is the more trustworthy of the two for anything sensitive, because the content never leaves your browser — it is hashed locally with crypto.subtle.digest and the result is base64-encoded before you ever see it. URL mode is a convenience for public CDN files: the server fetches the URL and hashes the response bytes directly, which saves you a copy-paste round trip. It is restricted to JavaScript and CSS responses, because those are the only content types SRI applies to and the only ones this tool can reliably hash byte-for-byte server-side.
The crossorigin attribute and CORS
This is the gotcha that catches people who copy an SRI tag without reading past the hash. Adding integrity to a cross-origin tag forces the browser to fetch it in CORS mode, which means the response must include an Access-Control-Allow-Origin header — if it doesn't, the browser blocks the resource outright, not just the integrity check. This tool checks for that header in URL mode and flags it when it's missing, because it is easy to generate a perfectly correct hash for a file that will then refuse to load in production.
Using the tag
Once you have a hash, the tag looks like this:
<script
src="https://cdn.example.com/app.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"
></script>For a stylesheet, use a <link rel="stylesheet"> tag with the same two attributes instead. Both forms are what this tool generates automatically, based on the file type it detects.
When hashes break
An SRI hash is only valid for one exact set of bytes. Any change to the file — a new library version, a re-minified build, even a CDN switching compression settings — invalidates it, and the resource will stop loading until you regenerate the hash. That is the intended behaviour, but it means SRI works best on files you pin to a specific, versioned URL rather than one that updates in place. If you self-host, update the hash as part of your deploy process rather than by hand.
Frequently asked questions
What is Subresource Integrity (SRI)?
SRI is a browser feature that lets you attach a cryptographic hash to a script or stylesheet tag. Before the browser executes the file, it hashes the bytes it actually downloaded and compares them to the hash in your tag. If a CDN, a compromised build pipeline, or an attacker on the network swaps the file for anything else, the hash will not match and the browser refuses to run it.
Do I need sha256, sha384, or sha512?
Any one of them is valid on its own — SRI does not require all three. sha384 is the conventional default and what most generators, including this one, put first: it is strong, and it is what tools like Bootstrap and jQuery publish by default. sha512 is marginally stronger and slightly larger; sha256 is the fastest to compute and still cryptographically sound for this purpose.
Why did my hash change when I did not touch the file?
SRI hashes cover the exact bytes served, not the source code you edited. A minifier version bump, a build timestamp injected into a comment, a different compression setting, or a CDN re-serving the file with different line endings will all produce a different hash even though the code looks unchanged. Regenerate the hash from the exact file your users will receive, not from a local copy.
Is this SRI hash generator free, and does it store what I paste?
It's free with no sign-up. Paste mode hashes your content entirely in your browser with the Web Crypto API — nothing you paste is uploaded, logged, or stored. URL mode necessarily sends the URL to our server so it can fetch the file, but the file content itself is discarded once the hashes are computed and returned to you.
Why does URL mode only work for JavaScript and CSS?
SRI is only meaningful for scripts and stylesheets — that's what the integrity attribute applies to. URL mode also needs to hash the exact bytes the browser will hash, and the safest way to guarantee that server-side is to restrict it to text content we can decode reliably. Anything else (fonts, images, binaries) should go through paste mode, or you can compute the hash locally.
What does the crossorigin attribute do, and do I need it?
crossorigin="anonymous" tells the browser to fetch the resource using CORS mode, which is required before SRI can be checked at all on a cross-origin request. If the file is on a different domain than your page and the response does not send Access-Control-Allow-Origin, the browser will refuse to load it — not just skip the check. Same-origin resources do not need it, but including it is harmless.
Can I list more than one hash in the same integrity attribute?
Yes. The integrity attribute accepts a space-separated list, e.g. integrity="sha384-… sha512-…", and the browser will accept the resource if any one of them matches. This is mainly useful during a migration between algorithms; for a new tag, one strong hash (sha384 or sha512) is enough.