AnyTool
Your files never leave your device. All processing happens locally in your browser.

How do I generate a Subresource Integrity (SRI) hash for a script or stylesheet?

Paste, type, or drag-drop the EXACT file you will serve; this tool digests the bytes locally with the Web Crypto API and outputs the SRI token — e.g. sha384-<base64> — plus the ready integrity attribute and a full <script> or <link rel="stylesheet"> tag with crossorigin. SHA-384 is the recommended default. It never fetches the URL and never uploads your file; everything runs in your browser.

  • Outputs sha256, sha384 and sha512 tokens at once — list several and the browser uses the strongest
  • Emits the exact integrity="sha384-…" attribute and a copy-paste <script> / <link> tag
  • crossorigin="anonymous" is added automatically (SRI forces a CORS fetch on cross-origin files)
  • Hash from the EXACT file you serve — any change, even one byte of whitespace, changes the hash
  • 100% client-side: never fetches your URL, never uploads your bytes, no server or CDN

What is

Subresource Integrity (SRI)

Subresource Integrity is a W3C security feature that lets an HTML author supply a cryptographic hash of an expected script or stylesheet in an integrity attribute. Before running a <script> or applying a <link rel="stylesheet">, the browser hashes the fetched bytes and refuses the resource unless a listed hash matches — so a compromised CDN or a tampered file cannot inject code. The attribute holds one or more <algorithm>-<base64-digest> tokens using sha256, sha384 or sha512.

Security & Privacy

Related terms

integrity attributecrossoriginCORSSHA-384SHA-512base64CDNsupply-chain attackContent Security Policyrequire-sri-forW3C SRI

Frequently Asked Questions

No. This tool hashes the file you paste or drop entirely in your browser with the Web Crypto API; it never fetches the URL you type and never uploads your bytes.

Everything is client-side. Your file or pasted text is read into memory and digested locally with crypto.subtle.digest, then base64-encoded into the SRI token — no network request, no server, no CDN and no telemetry are involved. Notably the tool does NOT fetch the resource URL you enter (that URL is only written into the generated tag), which means you must feed it the exact production bytes you will actually serve. Nothing is persisted, and it works offline once cached.

SHA-384 is the recommended default. You may list several; if you do, the browser validates with the strongest algorithm present (sha512 > sha384 > sha256).

The SRI spec allows sha256, sha384 and sha512, ordered weakest to strongest. SHA-384 is the widely recommended balance of security and hash length, which is why srihash.org and most guides default to it. You can include multiple tokens (even multiple algorithms) in one integrity attribute separated by spaces; the browser picks the strongest listed algorithm to verify, so listing sha384 and sha512 is safe future-proofing. Avoid relying on sha256 alone for new, high-value resources.

Because the served bytes changed. SRI hashes the exact file — a re-minify, a version bump, added whitespace, or a CDN that gzips or rewrites content all change the hash and cause a block.

SRI is byte-exact: the browser computes the hash of whatever it downloaded and compares it to your integrity value, refusing the resource on any mismatch. Common causes are pointing at a “latest” URL that silently updates, re-building or re-minifying the file, trailing-whitespace or line-ending changes, or a CDN/proxy that transforms the response. Always pin an exact, immutable version URL and re-generate the hash whenever the file legitimately changes. Because this tool never fetches the URL, generate the hash from the precise file the CDN will send.

Yes for cross-origin resources: SRI forces a CORS fetch, so add crossorigin="anonymous" and ensure the host sends CORS headers. SRI covers only <script> and <link rel="stylesheet"> — not @import, dynamic import(), images or the HTML page.

When a resource lives on another origin, the browser must fetch it with CORS to read its bytes for verification, so you must include crossorigin (anonymous unless you need credentials) and the server must return Access-Control-Allow-Origin — otherwise the resource is blocked before the hash is even checked. SRI applies only to <script> and <link rel="stylesheet"> elements; it does not protect CSS @import, dynamically import()-ed modules, images, fonts loaded via CSS, web workers, or the top-level HTML. And it verifies integrity, not safety: a hash of an already-malicious file still matches. Treat SRI as one hardening layer alongside CSP and version pinning.

Detailed Explanation

How It Works

What Subresource Integrity Is

Subresource Integrity (SRI) is a W3C security feature that lets an HTML author pin the exact content of a third-party script or stylesheet. The integrity attribute carries one or more cryptographic hashes, each written as an algorithm prefix, a dash and a base64-encoded digest (for example sha384-oqVuAf…). Before executing a <script> or applying a <link rel="stylesheet">, the browser hashes the bytes it downloaded and compares the result to the listed hashes; if none match it refuses the resource entirely, so a compromised CDN or a tampered file cannot silently inject code.

  • integrity="<alg>-<base64>" pins an expected script or stylesheet
  • The browser blocks the resource on any hash mismatch
  • Allowed algorithms: sha256, sha384, sha512 (SHA-2 family)
  • Defends against a compromised or tampered CDN / third-party host
  • Defined by the W3C Subresource Integrity specification
Technical Details

How the Hash Is Generated

An SRI hash is a SHA-256, SHA-384 or SHA-512 digest of the exact bytes of the resource, base64-encoded and prefixed with the algorithm name. On the command line this is `openssl dgst -sha384 -binary FILE | openssl base64 -A`. This tool does the identical computation locally with the browser’s native Web Crypto API (crypto.subtle.digest) over the bytes you paste, type or drag in, then base64-encodes the digest — producing sha256, sha384 and sha512 tokens at once. SHA-384 is the community default; when several tokens are listed the browser validates using the strongest algorithm present.

  • SRI token = base64(SHA-2 digest of the exact file bytes), algorithm-prefixed
  • Equivalent to openssl dgst -sha384 -binary | openssl base64 -A
  • Computed here with Web Crypto crypto.subtle.digest, no network
  • sha256, sha384 and sha512 generated simultaneously
  • Multiple tokens allowed; browser uses the strongest listed
Use Cases

crossorigin and the Generated Tag

Because verifying a cross-origin resource requires reading its bytes, SRI forces a CORS-mode fetch. That means a cross-origin <script> or <link> with integrity must also carry a crossorigin attribute (anonymous for no credentials, use-credentials to send cookies), and the host must return an Access-Control-Allow-Origin header — otherwise the browser blocks the resource before it even checks the hash. This tool assembles the full tag for you: <script src="…" integrity="sha384-…" crossorigin="anonymous"></script> or the matching <link rel="stylesheet">, with the URL you supply and an optional referrerpolicy.

  • SRI requires a CORS fetch for cross-origin resources
  • Add crossorigin="anonymous" (or use-credentials) to the tag
  • The host must send Access-Control-Allow-Origin or the file is blocked
  • Applies to <script> and <link rel="stylesheet"> only
  • The generated tag is copy-paste ready with your URL filled in
Limitations

Honest Limitations

SRI is byte-exact and unforgiving: any change to the served file — a re-minify, a version bump, one byte of added whitespace, or a CDN that gzips or rewrites the response — changes the hash and the browser blocks the resource. Always pin an exact, immutable version URL (never a “latest” alias) and re-generate when the file legitimately changes. SRI also has a limited scope: it covers <script> and <link rel="stylesheet"> only, not CSS @import, dynamic import(), images, fonts, web workers, or the top-level HTML. And it verifies integrity, not safety — a hash of an already-malicious file still matches. Because this tool never fetches the URL, you must feed it the precise bytes the server will send.

  • Any byte change (whitespace, re-minify, gzip rewrite) breaks the hash
  • Pin an exact version; never hash a mutable “latest” URL
  • Scope is <script> and <link rel="stylesheet"> only
  • Does not cover @import, dynamic import(), images or the HTML page
  • Verifies integrity, not safety; hash the exact production bytes
Privacy & Security

Private by Design

Everything happens on your device. The file or text you provide is read into memory and digested locally with the Web Crypto API; the tool never fetches the resource URL you type and never uploads your bytes, and there is no server, CDN or telemetry anywhere in the path. Your content is a value in memory only — nothing is persisted or logged, so closing the tab erases it. The tool works offline once cached, supports dark mode and a mobile-first layout, and the only optional network use on the site is consent-gated ads, which never see your file.

  • Hashed locally via Web Crypto crypto.subtle.digest
  • Never fetches the URL you enter; never uploads your file
  • No server, no CDN, no logging, no telemetry
  • Nothing persisted — closing the tab erases your content
  • Works offline once cached; dark-mode and mobile-first
SRI hash algorithms and what SRI does / does not cover
ItemDetailNotes
sha256256-bit SHA-2 tokenAllowed; fine, but prefer stronger for new resources
sha384384-bit SHA-2 tokenRecommended default — best security / length balance
sha512512-bit SHA-2 tokenStrongest; browser uses it when several are listed
Covered<script>, <link rel="stylesheet">These elements support the integrity attribute
NOT covered@import, import(), images, fonts, HTMLOutside SRI scope — pair with CSP
crossoriginRequired for cross-origin resourcesNeeds CORS headers or the file is blocked

SRI hashes the exact served bytes; any change breaks the match. Pin exact versions and re-generate on change. Everything in this tool runs locally in the browser. As of July 2026.