SRI Hash Generator

Generate a Subresource Integrity (SRI) hash for any CDN-hosted script or stylesheet. Paste the file's contents or load it from disk — the tool computes a sha256, sha384, or sha512 digest locally using WebCrypto and outputs the ready-to-paste integrity="sha384-…" attribute, plus full <script> and <link> tag snippets. Nothing leaves your browser.

How to use the SRI Hash Generator

There are two ways to provide the file:

  1. Paste contents — open the CDN URL in your browser, select all, paste into the textarea. The hash is over those exact bytes.
  2. Load from disk — if you downloaded the file, pick it with the file picker. The raw bytes are read locally via FileReader; nothing is uploaded.

Choose your algorithm. SHA-384 is the browser default and the one browsers have supported since SRI was introduced (Chrome 45+, Firefox 43+, Safari 11.1+). SHA-256 is shorter; SHA-512 offers the widest margin if you expect SHA-384 to be weakened.

Click Generate SRI. The output area shows:

  • The bare integrity attribute value, e.g. sha384-abc123…
  • A <script src="…" integrity="…" crossorigin="anonymous"></script> snippet ready to paste.
  • A <link rel="stylesheet" href="…" integrity="…" crossorigin="anonymous"> snippet.

Set Resource URL to populate the src and href in the snippets. The crossorigin="anonymous" attribute is required — SRI blocks the resource if CORS headers are absent.

About Subresource Integrity

Subresource Integrity (SRI) is a browser security feature defined in the W3C SRI spec that lets you lock a <script> or <link> tag to a specific byte sequence. When the browser fetches the resource, it hashes the response body and compares it to the base64-encoded digest in the integrity attribute. If they differ — because a CDN was compromised, the vendor silently patched the file, or a network attacker injected code — the browser refuses to execute or apply the resource and fires a SecurityPolicyViolation event.

The practical threat model is the supply-chain attack: an attacker who gains write access to a popular CDN can inject malicious code into libraries served to millions of sites. High-profile examples include the Polyfill.io compromise (2024) and several npm-to-CDN pipeline incidents. SRI makes this attack inert for pages that pin the hash. The downside: every time the vendor releases a new version, you must update the hash. Many teams generate the hash as part of their build pipeline to automate this.

SRI requires the CDN to serve the resource with CORS headers (Access-Control-Allow-Origin: * or your origin). If the CDN does not send CORS headers, the browser cannot complete the integrity check and blocks the resource. The crossorigin="anonymous" attribute on the tag opts in to the CORS fetch that makes SRI possible. Major CDNs (jsDelivr, cdnjs, unpkg, Google CDN) all support CORS for public files.

Common use cases

  • Third-party script pinning — lock jQuery, Bootstrap, or any CDN-served library to the exact version you tested against.
  • Build pipeline integration — generate hashes for your own static assets hosted on a CDN so end users get tamper-proof delivery.
  • Security audits — verify that a site's existing integrity attributes still match what the CDN serves.
  • CSP hardening — SRI hashes can be used in Content-Security-Policy script-src as an alternative to nonces for external scripts.
  • Compliance — PCI DSS 4.0 section 6.4.3 mandates an inventory and integrity mechanism for all page-level scripts; SRI satisfies this requirement for external resources.

Frequently asked questions

Which algorithm should I use — sha256, sha384, or sha512?
SHA-384 is the de-facto standard for SRI. It is supported by all browsers that implement SRI, offers a good security margin, and is what the official SRI spec examples use. SHA-512 adds extra margin at the cost of a longer attribute; SHA-256 is shorter but has a narrower margin.

Why must the hash match the exact CDN bytes?
The browser hashes the raw HTTP response body before decompression. Gzip/Brotli are transparent to SRI — the browser decompresses, then hashes the result. But if the CDN minifies differently per-request or adds any byte, the hash will not match. Always hash the bytes from the same URL you will reference.

Can I add multiple integrity hashes for the same resource?
Yes. The integrity attribute accepts a space-separated list, e.g. integrity="sha256-xxx sha384-yyy". The browser picks the strongest algorithm it supports and verifies against that hash only. This lets you transition between algorithms without breaking older browsers.

Does SRI work for inline scripts or styles?
No — SRI only applies to resources fetched from an external URL. For inline scripts you use a Content-Security-Policy nonce or hash in the script-src directive instead.

What happens if the CDN serves a different file version later?
The browser blocks the load and fires a network error. Your page will behave as if the script failed to load. This is by design — you must update the hash whenever the file changes. Locking the CDN URL to a specific version number (e.g. @5.3.0) alongside SRI prevents surprise hash mismatches.