What is Subresource Integrity (SRI)?
Subresource Integrity is a W3C web security feature that lets you pin a third-party resource — typically a JavaScript library or stylesheet loaded from a CDN — to an exact cryptographic hash. You add an integrity attribute to your <script> or <link> tag:
<script src="https://cdn.example.com/lib.min.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwDU2n"
crossorigin="anonymous"></script>Before executing the file, the browser recomputes its hash and compares it with yours. If even one byte differs, the resource is blocked. SRI protects you when a CDN is compromised, serves a tampered file, or silently ships a different version than the one you tested.
How to use this SRI hash generator
- Pick an input mode. Paste text, drop in one or more files (batch mode hashes them all at once), or enter a CDN URL to fetch and hash directly.
- Select algorithms. SHA-256, SHA-384 and SHA-512 are computed simultaneously — no need to run the tool three times.
- Copy the integrity value (format
sha384-<base64>) into your tag, or let the Snippet Builder generate the complete<script>/<link>tag withcrossorigin="anonymous"included. - Verify before deploying: use the Verify section to confirm a published hash matches your actual bytes, and read the troubleshooting guide if the browser rejects it.
Which algorithm should I use?
The SRI specification allows exactly three: SHA-256, SHA-384, and SHA-512.
- SHA-384 — the recommended default. It is what MDN examples and most documentation use, and it offers an excellent security margin with reasonably short hashes.
- SHA-256 — perfectly fine, and produces the shortest integrity values. A good choice when every byte of HTML counts.
- SHA-512 — the strongest of the three; use it when policy demands maximum strength.
You may also list several hashes space-separated in one attribute (integrity="sha384-… sha512-…"); the browser uses the strongest algorithm it supports.
Why not MD5 or SHA-1?
Browsers ignore integrity values that use any algorithm other than the three above — an md5-… or sha1-… value simply does nothing. Beyond the spec, MD5 and SHA-1 are cryptographically broken for collision resistance, making them a poor choice for tamper protection anyway.
Base64 vs hex
The integrity attribute requires base64: sha384-<base64-digest>. A hex digest will never validate — this is one of the most common "SRI not working" mistakes when people copy a hash from a checksum tool. This generator outputs base64 integrity values by default; the hex toggle exists only so you can compare against hex-based tools.
Generate an SRI hash from a URL
URL mode fetches the resource with your browser and hashes the received bytes — ideal for CDN links. It works when the server sends Access-Control-Allow-Origin (most public CDNs, including jsDelivr and cdnjs, do). If the server blocks cross-origin reads you get an explicit CORS error; in that case download the file and hash it in File mode. Identical bytes always produce identical hashes, however you obtain them.
.gz / .br archive. Browsers verify the hash against the resource bytes after decompression, so hashing the compressed transfer will always mismatch.Can I use SRI for images?
Honestly: not via the integrity attribute. Browsers only enforce SRI on <script> and <link rel="stylesheet"> (plus a few fetch-driven contexts). An integrity attribute on an <img> is ignored. If you need to verify an image's integrity, fetch it with JavaScript and compare hashes manually — or hash it in File mode here for your own records.
Code examples — generate SRI hashes yourself
No server API is needed (and this tool deliberately has none — see the FAQ). One-liners for your own pipeline:
JavaScript (browser, WebCrypto)
const bytes = new TextEncoder().encode(data);
const digest = await crypto.subtle.digest('SHA-384', bytes);
const b64 = btoa(String.fromCharCode(...new Uint8Array(digest)));
const integrity = 'sha384-' + b64;Node.js (nodejs)
const { createHash } = require('crypto');
const fs = require('fs');
const integrity = 'sha384-' + createHash('sha384').update(fs.readFileSync('app.js')).digest('base64');Python
import hashlib, base64
digest = hashlib.sha384(open('app.js', 'rb').read()).digest()
integrity = 'sha384-' + base64.b64encode(digest).decode()PHP
$integrity = 'sha384-' . base64_encode(hash('sha384', file_get_contents('app.js'), true));Java
MessageDigest md = MessageDigest.getInstance("SHA-384");
String integrity = "sha384-" + Base64.getEncoder().encodeToString(md.digest(data));Shell (openssl)
openssl dgst -sha384 -binary app.js | openssl base64 -A | sed 's/^/sha384-/'Troubleshooting — why is my integrity check failing?
When the browser blocks a resource with "Failed to find a valid digest in the 'integrity' attribute", work through this list. Each cause is explained below, in rough order of frequency:
- Whitespace or line-ending changes. The #1 cause. The file you hashed is not byte-identical to the file served: a trailing newline added by your editor, CRLF converted to LF on deploy, or a minifier touching the file. Re-hash the exact bytes the server sends (download it and use File mode).
- Wrong file version. You hashed v1.2.3 but the CDN URL now serves v1.2.4, or the CDN minifies/beautifies on the fly. Pin exact versions in CDN URLs.
- Hex instead of base64. The integrity attribute requires base64. Hex digests from checksum tools will never validate.
- Missing
crossorigin="anonymous". For cross-origin resources the browser needs this attribute to read the bytes for verification. Without it, the check silently fails open. - Hashed the compressed file. Hash the original file, not the
.gz/.brtransfer (see note above). - Wrong algorithm prefix.
sha384-must match the digest that follows; only sha256/sha384/sha512 are accepted. - Byte-order mark (BOM). An invisible UTF-8 BOM at the start of the file changes the hash. Compare with a hex dump if all else fails.
Shortcut: paste the published integrity value into the Verify section above together with your actual file — it tells you immediately whether the bytes match.
How this compares to other SRI generators
| Feature | This tool | srihash.org | report-uri.com SRI |
|---|---|---|---|
| Text input | Yes | No (URL only) | — |
| File upload, batch mode | Yes, multi-file | — | — |
| Hash from URL | Yes (with honest CORS errors) | Yes | — |
| SHA-256 / 384 / 512 at once | Yes | Yes | Limited |
| Hex / base64 toggle | Yes | No | No |
<script> / <link> snippet builder | Yes | No | No |
| Verify existing hash | Yes | No | No |
| Troubleshooting guide | Yes (7 causes) | Basic docs | No |
| Privacy (client-side) | Yes, 100% | Yes | Yes |
Comparison checked October 2026. srihash.org is the canonical community tool (linked from MDN Web Docs) — this tool aims to be its more complete companion, not a replacement for its simplicity.
Documentation
- MDN Web Docs — Subresource Integrity
- W3C — Subresource Integrity specification
- caniuse.com — browser support for SRI
Frequently asked questions
What is Subresource Integrity (SRI)?
Subresource Integrity is a W3C web security feature that lets you lock a third-party resource (a JavaScript library or stylesheet from a CDN) to an exact cryptographic hash. You add an integrity attribute to your <script> or <link> tag. Before executing the file, the browser recomputes its hash and compares it with yours — if they differ, the resource is blocked. So what is it in one sentence? A tamper-evident seal for third-party files.
How do I generate an SRI hash?
Choose Text, File, or URL input above, tick SHA-256/384/512, and click Generate hashes. Copy the sha384-… integrity value into your tag, or use the Snippet Builder to generate the complete tag.
Which algorithm should I use — SHA-256, SHA-384, or SHA-512?
SHA-384 is the recommended default. SHA-256 gives shorter hashes; SHA-512 is the strongest. Browsers support all three, and you can list several space-separated in one attribute.
Why can't I use MD5 or SHA-1 for SRI?
The SRI spec only allows SHA-256, SHA-384, and SHA-512 — browsers ignore anything else. MD5 and SHA-1 are also cryptographically broken for collision resistance.
Base64 or hex for the integrity attribute?
Base64, always: sha384-<base64>. Hex digests never validate — a classic "SRI not working" mistake.
Why is my integrity check failing?
Usually whitespace/line-ending differences, a different file version than served, hex instead of base64, a missing crossorigin="anonymous", or hashing the gzipped file. See the troubleshooting guide above, or use the Verify section.
Can I generate a hash from a URL?
Yes, in URL mode — it works when the server allows cross-origin reads (most public CDNs do). Otherwise download the file and use File mode.
Does SRI work for images?
No — browsers only enforce SRI on <script> and stylesheets. An integrity attribute on <img> is ignored.
Does SRI use salt?
No. Salt belongs to password hashing. SRI never hashes with salt — it must be deterministic — the same file must always produce the same integrity value.
How do I generate SRI hashes in Python?
import hashlib, base64 → 'sha384-' + base64.b64encode(hashlib.sha384(data).digest()).decode(). See the Code examples section for the full snippet.
How do I generate SRI hashes in Node.js?
'sha384-' + require('crypto').createHash('sha384').update(data).digest('base64').
Is there an API for this generator?
No — everything runs in your browser, so your files are never uploaded. Automate with the one-liners in Code examples.
Do I need crossorigin="anonymous"?
Yes, for cross-origin resources. Without it the browser cannot read the bytes to verify, and the check silently fails open.
Can I include multiple hashes in one integrity attribute?
Yes, space-separated (e.g. integrity="sha384-… sha512-…"). The browser uses the strongest algorithm it supports.
SRI vs CSP — what's the difference?
SRI verifies individual files byte-for-byte; CSP controls which sources may load at all. Use both — see our CSP generator.
Is my file uploaded anywhere?
No. Hashing happens locally with WebCrypto; files never leave your browser.
Privacy & security notes
This generator is 100% client-side: your files and pasted content never leave your browser — there is no server to send them to. Hashes are computed with the Web Crypto API (the same SHA-2 implementation your OS ships). The tool is defensive by design: it helps you harden websites against supply-chain attacks on third-party scripts and stylesheets.