SRI Hash Generator
Generate Subresource Integrity hashes for external JS/CSS.
External JS and CSS loaded from a CDN can run malicious code on your site if the origin server is tampered with. Subresource Integrity (SRI) is a security standard that pins a cryptographic hash of the file so the browser only executes it when the bytes it actually received match. This SRI hash generator turns pasted file contents into an integrity hash using the sha256, sha384 or sha512algorithm.
Add the generated integrity attribute together with crossorigin="anonymous"and the browser will refuse to load the resource if even a single byte changes. All hashing runs entirely in your browser via the Web Crypto API, so the file contents never leave your machine.
How is an SRI hash built?
An SRI hash is the full file bytes run through a hash function, the digest Base64-encoded, and prefixed with the algorithm name. For example:sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC. You can list multiple algorithm hashes separated by spaces; the browser picks the strongest one it supports.
- sha256 — most widely compatible but the smallest security margin.
- sha384 — a good balance of security and compatibility; the recommended default.
- sha512 — the strongest and longest option.
Applying it in HTML
For external scripts, set both integrity and crossorigin on the<script> tag. Stylesheets work the same way on<link rel="stylesheet">.
- Paste the exact file contents you will ship (the minified/bundled final artifact).
- Copy the generated
integrityvalue. - Always include
crossorigin="anonymous"— without it the check does not run.
When auditing third-party resources, it also helps to review their response headers with the security headers checker to confirm CSP, HSTS and the like are configured alongside integrity.
Hash length by algorithm
Each algorithm produces a different digest size, so the Base64 portion of the integrity string has a fixed length. If your output does not match the lengths below, it was probably copied incorrectly. (Lengths count the Base64 body only, excluding the 7-character sha###- prefix.)
| Algorithm | Digest | Base64 body length | Best for |
|---|---|---|---|
sha256 | 32 bytes | 44 chars (ends in one =) | Maximum legacy compatibility |
sha384 | 48 bytes | 64 chars (no padding) | Recommended default |
sha512 | 64 bytes | 88 chars (ends in ==) | When you need the strongest guarantee |
Worked example — jQuery slim build
Here is a real CDN snippet carrying two algorithms at once. The browser verifies with the strongest one it supports (here sha512), and the load passes if either hash matches the bytes received.
<script
src="https://code.jquery.com/jquery-3.7.1.slim.min.js"
integrity="sha256-kmHvs0B+OpCW5GVHUNjv9rOmY0IvSIRcf7zGUDTDQM8=
sha512-v2CJ7UaYy4JwqLDIrZUI/4hqeoQieOmAZNXBeQyjo21dadnwR+8ZaIJVT8EE2iyI61OV8e6M8PP2/4hpQINQ/g=="
crossorigin="anonymous"
referrerpolicy="no-referrer"></script>You can list several hashes inside one attribute separated by whitespace; newlines and indentation count as separators too, so feel free to wrap them across lines for readability.
Common pitfall
- Line endings and encoding matter: SRI hashes the entire file byte-for-byte. CRLF (Windows) differs from LF, and a single UTF-8 BOM byte changes the hash completely. Always paste the exact minified artifact the CDN serves — hashing the original source or a reformatted copy will get the resource blocked.
- Compression is irrelevant: even if the server sends gzip or Brotli, the browser verifies the decompressed bytes. So hash the uncompressed file content — never paste the compressed payload.
- Never hand-edit the hash: flipping one Base64 character breaks verification. The separator between prefix and digest must be a hyphen (
sha384-), not an equals sign (sha384=).