Subresource Integrity (SRI) Hash Generator
Generate the sha256/384/512 integrity hash for any script or stylesheet — so a compromised CDN can't silently swap what your site loads.
Also known as: SRI generator, Subresource integrity hash tool, CDN integrity hash generator, Script integrity hash generator
How it works
- 1Drop a local JS or CSS file, or paste a URL to fetch one.
- 2Copy the sha384 hash (the common default) or any of the three algorithms shown.
- 3Edit the URL field to match where the file will actually be hosted.
- 4Copy the generated <script> or <link> tag into your page.
Why use Subresource Integrity (SRI) Hash Generator
Exact-byte hashing via Web Crypto
Uses the browser's own cryptographic API to hash a file's real bytes — the same digest a browser checks when it loads the resource.
Local files never leave your browser
Drop in a file and every hash is computed on-device; nothing is uploaded for the local-file path.
All three standard algorithms at once
sha256, sha384, and sha512 are all generated together, so you can match whatever a snippet or policy expects.
Ready-to-paste tag snippet
Generates the full <script> or <link> tag with the integrity and crossorigin attributes already filled in.
Server-side fetch clearly disclosed
The optional "hash a URL" path is the one server-touching step, and it's labeled plainly — no hidden network calls.
Free, unlimited, no signup
No account or API key required for either the local-file or URL path.
Who uses Subresource Integrity (SRI) Hash Generator
Self-hosting a script pulled from a CDN snippet
Generate the matching integrity hash when copying a <script> tag from a library's official CDN instructions.
Pinning a CDN-hosted script against tampering
Add SRI to third-party scripts your site already loads, so a compromised CDN can't silently change what runs on your pages.
Verifying a vendor-provided hash
Confirm a hash a vendor or library maintainer published actually matches the file you have.
Meeting a security audit or CSP requirement
Generate compliant integrity hashes when a security review or Content-Security-Policy requires SRI on external resources.
Hashing a static site generator's build output
Generate integrity hashes for bundled JS/CSS files before referencing them in a hand-written HTML template.
Learning how Subresource Integrity works
See exactly how a file's bytes turn into the hash a browser checks, without needing a build tool to try it.
About Subresource Integrity (SRI) Hash Generator
Loading a script from a third-party CDN means trusting that CDN completely — if it's ever compromised, every site pulling from it loads whatever the attacker put there, no questions asked. Subresource Integrity closes that gap: you publish the expected hash of the file alongside the URL, and the browser refuses to execute anything that doesn't match, turning a silent supply-chain compromise into a loud, visible failure instead.
For a local file, this tool reads its exact bytes with the Web Crypto API and hashes them directly in your browser — nothing is uploaded. If you only have a URL (say, a CDN link you're about to paste into a page), fetching it is the one step that has to run server-side, since a browser tab can't read another origin's response bytes over a plain fetch; that fetch is SSRF-guarded and only the computed hash is kept, never the file's contents.
sha384 is the most common default in the wild — it's what the standard Bootstrap and jQuery CDN snippets use — but this tool generates all three standard algorithms so you can match whatever a security policy or existing snippet expects. Whichever you use, the integrity attribute has to be paired with crossorigin="anonymous" on the tag, or the browser won't apply the check at all.
One real-world catch worth knowing: SRI only works if the server hosting the file sends proper CORS headers (Access-Control-Allow-Origin). If it doesn't, adding an integrity attribute doesn't get ignored — it makes the browser refuse to load the resource entirely, which is exactly why it's worth testing a page after adding SRI, not just after generating the hash.
Subresource Integrity (SRI) Hash Generator vs. other options
How Open Tools Library compares to desktop software and other online tools.
| Feature | Open Tools Library | Desktop software | Other online tools |
|---|---|---|---|
| Price | Free, unlimited | N/A | Often free |
| Exact-byte hashing | Real Web Crypto digest of the actual file | N/A | Varies — some re-encode text first |
| Local file support | Yes — hashing never leaves your browser | N/A | Often requires uploading the file |
| Algorithms offered | sha256, sha384, and sha512 together | N/A | Sometimes only one |
| Tag snippet generation | Full <script>/<link> tag, ready to paste | N/A | Often just the raw hash |
| Content privacy | Local files never uploaded; URLs disclosed clearly | N/A | Often unclear what's sent where |
Pro tips
- sha384 is the most common default in real-world use — it's what the official Bootstrap and jQuery CDN snippets use.
- The integrity attribute does nothing on its own — it has to be paired with crossorigin="anonymous" on the same tag, or the browser skips the check entirely.
- SRI only works if the hosting server sends CORS headers (Access-Control-Allow-Origin) — without them, adding integrity makes the browser refuse to load the resource at all, not silently skip the check.
- Re-generate the hash any time the file changes — a stale hash makes the browser block the file instead of loading a mismatched version, which is exactly the point, but worth remembering after every update.
Technical specs
- Algorithms
- sha256, sha384, sha512 — generated together
- Local file hashing
- 100% client-side via the Web Crypto API
- URL fetch (optional)
- Server-side, SSRF-guarded, max 5 MB — only the hash is kept
- Output
- Base64-encoded integrity string plus a ready <script>/<link> tag
- File types
- Any file — most useful for JS and CSS
- Processing location
- Local for uploaded files; server-side only for the optional URL fetch
Privacy & security
A tool for verifying file integrity shouldn't need to see the file's contents to do it.
Hashing a local file runs entirely in your browser via the Web Crypto API — the file itself is never uploaded.
The optional URL-fetch path only ever returns the computed hash, never the file's contents.
No account, no email, no login required for either path.
Equally private whether you're hashing a small stylesheet or a large bundled script.
Frequently asked questions
What is Subresource Integrity?
A browser feature where you publish the expected hash of a script or stylesheet alongside its URL — the browser refuses to execute the file if its actual contents don't match that hash.
Do I need crossorigin along with integrity?
Yes — crossorigin="anonymous" is required on the same tag for SRI to be checked at all, and the server must respond with CORS headers for the resource to load.
Why generate three different hashes?
sha256, sha384, and sha512 are all valid for SRI — generating all three means you can match whatever a specific snippet, library, or policy expects without recomputing anything.
Is my file uploaded anywhere?
Not for a local file — hashing runs entirely in your browser via the Web Crypto API. Only the optional "fetch from URL" path touches our server, and only to compute the hash.
Can I hash a file that's already hosted online instead of on my device?
Yes — paste its URL and the server-side fetch path will retrieve it and compute the hash; only the hash is returned, never the file's contents.
What happens if the hosted file changes after I generate the hash?
The browser will block it — SRI is designed to fail closed. Re-generate the hash here whenever you update the file.
Troubleshooting
My page broke after I added the integrity attribute
Either the hash doesn't match the file's current bytes, or the crossorigin="anonymous" attribute is missing from the tag — both cause the browser to block the resource rather than load a mismatched version.
The "fetch from URL" option failed
The target server may not send CORS headers, the file may be over the 5 MB limit, or the URL may point to a private/internal address that's blocked for safety — the error message will say which.
Which algorithm should I use?
sha384 is the de facto standard — it's what official CDN snippets for major libraries use. sha256 and sha512 work identically if a specific policy requires them.
The hash doesn't match what the CDN publishes
Double check you're hashing the exact same file version — even a minor version bump on a CDN URL changes every byte, and therefore the hash.
Related searches
Landed here looking for something worded a little differently? Subresource Integrity (SRI) Hash Generator covers all of these too:
Ready to use Subresource Integrity (SRI) Hash Generator?
Free, private, and ready right now — no signup required.
Scroll to Subresource Integrity (SRI) Hash Generator