SRI hash generator

What is Subresource Integrity?

When a page loads a script from someone else's server — a CDN, an analytics vendor, a font host — it is trusting that server completely. Whatever bytes come back get executed with the full privileges of your page. If that server is compromised, or simply serves something different one day, your visitors run it.

Subresource Integrity is the fix. You put a cryptographic hash of the file you expect into an integrity attribute on the script or link tag. The browser downloads the file, hashes it, and refuses to execute it unless the hash matches. A CDN that gets compromised now breaks your page instead of owning it, which is a far better failure.

The attribute looks like sha384- followed by a base64 string. This page computes that string from a file you pick or text you paste, gives you the complete tag to copy, and — in the other mode — takes an attribute you already have and tells you whether a browser would accept it.

How to use it

1. Give it the exact bytes of the file. Choose the local file or paste its contents. The hash is of the bytes as they are served, so a single trailing newline changes the answer — this is why generating from a copy that your editor reformatted will not match.
2. Pick your algorithm and copy the tag, not just the value. sha384 is the usual choice and the one the specification's own examples use. The generated tag includes crossorigin, which is not optional for a cross-origin file.
3. Or switch to Check to test an attribute you already have. Paste the integrity attribute alongside the file and you get a verdict, the algorithm the browser would actually consult, and a list of any expressions that were ignored.

A second algorithm replaces the first, it does not back it up

This is the rule the page is built around, and almost nobody knows it. When an integrity attribute lists several hash expressions, the browser does not check them all, and it does not accept a match against any of them. The specification says it chooses the strongest hash function in the list and uses only that, discarding every weaker one before any comparison happens. The order is fixed: sha256 is weaker than sha384, which is weaker than sha512.

The consequence is sharp. If you list a correct sha256 and a mistyped sha512, your file is blocked — the correct hash is thrown away unread. If you list a mistyped sha256 and a correct sha384, your file loads perfectly, and the broken hash never mattered. Adding a second algorithm feels like defence in depth and is nothing of the sort; it is a replacement, and it silently moves all your trust onto whichever one is strongest.

There is a case where multiple hashes genuinely mean any of these, and it is the useful one: several expressions using the same algorithm. That is how you allow two acceptable builds of a file during a rollout, and the browser will accept a match against any of them. So sha384-A sha384-B is a real either-or, while sha256-A sha512-B is not.

When you check an attribute here, anything discarded by that rule is listed separately, because the rule is invisible in the attribute itself and a verdict without it would be a mystery.

Two other things that quietly break it

The first is the missing crossorigin attribute. Integrity-protected requests to another origin are required to use CORS, so a script tag pointing at a CDN with an integrity attribute and no crossorigin does not load at all — and the failure looks exactly like a wrong hash, which sends people off recomputing a value that was correct all along. Every tag this page generates includes crossorigin="anonymous". It also means the CDN itself has to send permissive CORS headers; if it does not, you cannot use SRI with it.

The second is how the value is computed. The specification says to apply the hash algorithm to the bytes and then base64 encode the result — base64 of the raw digest. A great many hand-rolled attempts hash to a hexadecimal string first and base64 that instead, which produces a value that looks right and never matches. The lengths give it away: a sha384 digest is 48 bytes and encodes to 64 base64 characters, while base64 of its 96-character hex spelling is 128. The generator shows both side by side so the difference is visible rather than asserted.

One more, less dramatic: a browser that does not recognise an algorithm ignores that expression rather than rejecting the file. That is deliberate, and it is what lets you add a future algorithm today without breaking anything — but it also means an attribute full of algorithms nobody supports protects nothing at all.

Honest limits

This page cannot fetch a URL for you. A browser is not allowed to read a cross-origin file from a script unless that server opts in with CORS — the same rule that makes crossorigin mandatory on the tag. So you pick the local file or paste the contents, and any tool that appears to fetch the URL for you is doing it on a server, which means trusting that server with the fetch. Doing it locally is both the honest option and the private one.

The hash covers the bytes and nothing else. It does not tell you the file is safe, well-written or from who you think — only that it has not changed since you took the hash. If you hash a compromised file, SRI faithfully guarantees you the compromised file.

It also pins you to one version. Any update to the file, including a security fix the vendor ships, will fail the check until you regenerate the value. That is the trade SRI makes, and it is why it suits versioned URLs far better than a floating latest.

Finally, integrity applies to scripts and stylesheets. It is not a general mechanism for images, fonts or fetch requests, so a tag generated here belongs on a script or link element and nowhere else.

Why is it free?

Because it costs nothing to run. The hashing happens in your browser through the Web Crypto API that is already there; the file you choose never leaves your machine, nothing is uploaded and no server sees it.

No account, no sign-up, nothing held back. The rules come from the Subresource Integrity specification itself, and the checks that verify them use the specification's own published example digests, cross-checked against a separate implementation.