SRI Hash Generator

Computes a Subresource Integrity hash for any file — paste the content directly, or try fetching it from a URL. The output is a ready-to-paste integrity attribute that tells the browser to refuse loading the file if a single byte of it has changed since you generated the hash.

What SRI actually protects against

Every time you load a script or stylesheet from someone else's CDN, you're trusting that CDN not to have been compromised — and CDN compromises are a real, recurring category of supply-chain attack, not a hypothetical one. SRI closes that gap: the browser hashes the file it actually receives and compares it against the integrity attribute you specified. Match, it loads normally. Mismatch — because the CDN was compromised, or a cache got poisoned, or anything else changed the bytes — the browser refuses to execute it at all, silently and safely, rather than running code that's no longer what you originally vetted.

Why fetching by URL often just doesn't work

Browsers block JavaScript on one origin from reading the response body of a fetch to a different origin unless that origin explicitly opts in with CORS headers — which is a security feature, not a bug, and it applies here just as much as anywhere else. Plenty of CDNs do send permissive CORS headers specifically because they expect to be fetched cross-origin (that's the whole point of a public CDN), but plenty of others don't, and there's no way to know in advance without trying. Pasting the file content directly sidesteps the problem entirely — view-source or curl the file yourself, paste the raw text in, and the hash is computed the same way either way.

SHA-384 is the sensible default, not an arbitrary pick

The SRI spec explicitly recommends SHA-384 as the baseline algorithm — strong enough that there's no realistic collision concern, without the extra size and computation of SHA-512 for no real security benefit at this data scale. Most CDNs that publish integrity hashes themselves default to SHA-384 for exactly this reason, which is also why this tool defaults to it.

The part that's easy to forget

Add crossorigin="anonymous" alongside the integrity attribute — without it, the browser won't expose enough information about the cross-origin response to actually perform the integrity check, and SRI silently does nothing. And remember that a hash is tied to the exact bytes of the file at generation time: if the CDN updates the file later (even a patch version bump on an "unversioned" URL), your integrity hash goes stale and every page using it breaks until you regenerate the hash against the new content.