Free SRI hash generator. Paste a CDN URL, upload a file or paste code to get sha256, sha384 or sha512 integrity attributes and a ready-to-copy script tag.
This SRI hash generator produces the integrity value you attach to a <script> or <link> tag so the browser will refuse to run a third-party file that has been altered. Give it a CDN URL, upload a file from disk, or paste the source directly, and it returns a base64-encoded SHA-256, SHA-384 or SHA-512 digest formatted exactly as Subresource Integrity expects — plus the complete HTML tag, with the crossorigin attribute already set, ready to paste into your template.
Hashing happens entirely in your browser through the Web Crypto API (crypto.subtle.digest). Pasted source and uploaded files never leave your machine, which means you can generate integrity hashes for unreleased internal bundles without shipping them to a third party first.
When you load jQuery, a font loader or an analytics snippet from a public CDN, you are executing code you do not control on your own origin, with full access to your DOM, your cookies and your forms. If that CDN is compromised, or an intermediary tampers with the response, the injected code runs with your site's privileges. Subresource Integrity closes that gap. The browser fetches the resource, computes its cryptographic digest, and compares it against the value you declared. On a mismatch it discards the response and fires an error event — the script never executes and the stylesheet never applies.
The critical property is that verification is done by the browser, not by you or the CDN. An attacker who controls the CDN cannot supply a matching hash for modified content without breaking SHA-2, and an attacker who controls the network cannot rewrite your HTML if it is served over HTTPS.
The value is a hash expression: the algorithm prefix, a hyphen, then the base64 encoding of the raw digest bytes. Note that it is base64 of the binary digest — not base64 of the hex string, which is the single most common mistake when people generate these by hand.
<script src="https://cdn.example.com/lib.min.js" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC" crossorigin="anonymous"></script>
For a stylesheet the shape is the same: <link rel="stylesheet" href="https://cdn.example.com/app.css" integrity="sha384-..." crossorigin="anonymous">
Three details decide whether it works in practice:
crossorigin is mandatory for cross-origin resources. Without it the response is an opaque one that the browser will not read, so integrity checking cannot happen and the resource is blocked outright. Use anonymous for public CDN assets and use-credentials only when the request must carry cookies. The CDN must also return a permissive Access-Control-Allow-Origin header — this tool reports whether the URL you fetched does.integrity="sha384-abc... sha512-def..."). The browser picks the strongest algorithm it recognises and requires only that one to match. Selecting several algorithms here produces exactly that, which is useful during a migration where two builds may be served.@latest alias, whose whole purpose is to change underneath you.The SRI specification defines exactly three: sha256, sha384 and sha512. MD5 and SHA-1 are not permitted and browsers ignore them. All three produce a value your users' browsers compute at load time, so the cost difference is negligible in practice — the digest is calculated once per resource fetch, over a file that is typically tens of kilobytes.
If you want raw digests for a purpose other than SRI — verifying a download, comparing file copies — the general hash generator gives you hex output across more algorithms.
crossorigin to anonymous unless the resource requires credentials, and tick async or defer if your script tag needs them.integrity attribute, and the complete <script> or <link> tag. Copy the tag or download the output.To check an existing tag rather than create one, fetch the same URL here and compare the generated hash against the integrity value already in your HTML. A mismatch means the file changed since the attribute was written — which is precisely the condition SRI exists to catch.
Individual tags are opt-in, so a single forgotten script defeats the policy. Content Security Policy provides require-sri-for script style, which instructs the browser to reject any script or stylesheet loaded without an integrity attribute. Support has been uneven across browsers and the directive has drifted through the W3C process, so treat it as defence in depth rather than a guarantee, and keep a lint rule in CI that fails a build when a cross-origin <script src> lacks integrity. You can assemble the surrounding policy with the CSP generator and confirm what your site actually sends using the security headers analyzer.
An SRI hash is a cryptographic digest of a script or stylesheet, written as algorithm-base64digest in the integrity attribute of a tag. The browser recomputes the digest of what it downloaded and refuses to use the file unless the two match.
Yes — free, no account, no limit on how many hashes you generate.
sha384 is the conventional default and what most CDNs publish. sha256 produces the shortest attribute and remains cryptographically sound; sha512 gives the widest margin. All three are valid SRI algorithms and all are widely supported.
Usually one of three causes: the crossorigin attribute is missing on a cross-origin resource, the CDN does not send an Access-Control-Allow-Origin header, or the file changed after you generated the hash. The browser console names which of these applies.
For any resource on a different origin, yes. Without it the browser receives an opaque response it cannot inspect, so integrity cannot be verified and the load is blocked. Same-origin resources do not require it.
Yes. Separate hash expressions with whitespace. The browser selects the strongest algorithm it supports and only that one must match — helpful when two builds of a file may be served during a rollout.
Yes. Fetch the same URL in URL mode and compare the generated value with the one in your markup. If they differ, the file has been modified since the attribute was written.
Yes, if you set the property when creating the element: assign el.integrity and el.crossOrigin before appending the node to the document. Setting them afterwards is too late.
No. Digests are computed locally with the Web Crypto API. Uploaded and pasted content stays in the browser. Only the URL mode makes a network request, and that request goes to the CDN you named.
It adds little security — an attacker who can alter those files can alter the HTML that declares the hash — and it adds a real maintenance cost, since every rebuild changes the digest. Reserve SRI for third-party origins you do not control.
A Content Security Policy directive, written require-sri-for script style, that tells the browser to block scripts or stylesheets loaded without an integrity attribute. Browser support has been inconsistent, so pair it with a CI check rather than relying on it alone.
Subresource Integrity (SRI) is a web security feature that allows browsers to verify that files fetched from CDNs and third-party servers have not been tampered with. By adding a cryptographic hash to <script> and <link> tags, SRI ensures that the browser only executes resources that match the expected content. If a CDN is compromised and serves malicious code, SRI-protected pages will refuse to load the altered resource.
Supply chain attacks targeting CDN-hosted JavaScript libraries are a growing threat. The 2018 event-stream incident, the 2021 ua-parser-js compromise, and numerous attacks on npm packages demonstrate that third-party code can be weaponized. SRI is the browser-native defense against these attacks—no additional libraries or services required.
SRI uses cryptographic hash functions to create a fingerprint of the expected file contents:
integrity attributeExample:
<script src="https://cdn.example.com/lib.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8w"
crossorigin="anonymous"></script>
| Hash Algorithm | Output Length | Recommendation |
|---|---|---|
| SHA-256 | 256 bits (64 hex chars) | Minimum acceptable |
| SHA-384 | 384 bits (96 hex chars) | Recommended (best balance) |
| SHA-512 | 512 bits (128 hex chars) | Maximum security |
Multiple hashes: You can include multiple hashes for forward compatibility when updating resources:
integrity="sha384-abc123... sha384-def456..."
The crossorigin="anonymous" attribute is required for SRI on cross-origin resources; without it, the browser cannot verify the hash.
<script> and <link rel="stylesheet"> loaded from third-party originsrequire-sri-for directive to mandate SRI for all scripts and styles on your pagesSubresource Integrity (SRI) ensures external resources (CDN JS/CSS) have not been tampered with. Browser verifies file hash matches integrity attribute before executing. Example: script with src attribute pointing to https://cdn.example.com/lib.js with integrity sha384-abc123 and crossorigin anonymous. If file modified (CDN compromise, MITM attack), hash will not match and browser blocks execution. Benefits: prevent CDN compromise, detect file modifications, supply chain security, compliance requirements (PCI DSS). Required for: external resources from CDN, third-party libraries, cross-origin files. W3C standard, supported by all modern browsers. This tool generates SRI hashes for any JS/CSS file instantly.
SRI supports SHA-256, SHA-384, SHA-512. Recommendations: SHA-384 most common (balance of security and size), SHA-512 maximum security (longer hash), SHA-256 faster but less secure (still acceptable). You can specify multiple: integrity="sha384-abc123 sha512-def456" (browser uses strongest it supports). Performance: negligible difference for small files, SHA-384 recommended by most CDNs (jsdelivr, cdnjs). Hash format: algorithm-base64hash. Example: "sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC". Security: all three are cryptographically secure for SRI purpose. This tool generates all three algorithms - choose based on your security policy.
Add integrity and crossorigin attributes to script/link tags. Steps: 1) Get hash from CDN (many provide it) or generate with this tool. 2) Add to HTML: <script src="https://cdn.jsdelivr.net/npm/vue@3" integrity="sha384-..." crossorigin="anonymous"></script>. 3) Test: browser console shows error if hash mismatch. Requirements: crossorigin attribute required (CORS), HTTPS only (SRI does not work on HTTP), same hash for same file (cache-friendly). Common CDNs with SRI: jsdelivr.com (shows SRI hash), cdnjs.com (copy SRI button), unpkg.com (generate hash). For self-hosted: generate hash during build, include in HTML templates. This tool generates production-ready SRI snippets.
Browser blocks resource execution and fires error event. Console shows: "Failed to find a valid digest in the 'integrity' attribute for resource 'URL'". Consequences: script does not run (may break page functionality), CSS does not apply (visual issues), onerror event fires (can catch with JavaScript). Common causes: file updated on CDN (new version), typo in hash value, wrong file URL, CORS misconfiguration (missing crossorigin). Debugging: check browser console, verify file content matches hash, regenerate hash, ensure CORS headers present. Fallback strategy: use <script onerror="..."> handler to load local copy if CDN fails. Update hashes when upgrading library versions. This tool helps verify current file matches expected hash.
Integrate into build pipeline for automated hash generation. Methods: webpack-subresource-integrity plugin (Webpack), vite-plugin-sri (Vite), generate with command line: openssl dgst -sha384 -binary file.js | openssl base64 -A, Node.js script with crypto module. Build process: 1) Build assets (minify JS/CSS). 2) Generate SRI hash for each file. 3) Inject into HTML template. 4) Deploy assets and HTML together. Version control: commit hashes with code, update on file changes only. CI/CD: automate hash generation on every deployment. Popular tools handle automatically. This tool useful for: local development, manual verification, one-off hash generation, learning SRI concepts.
SRI only works for external resources (separate file URLs), not inline scripts/styles. Inline scripts have no integrity attribute. External scripts with src attribute pointing to https://cdn.example.com/file.js with integrity attribute work with SRI. For dynamic content: if file changes frequently, SRI problematic (hash changes). Solutions: versioned URLs (lib-v1.2.3.js), build-time hash generation, accept hash updates on deployments. Dynamic loading (JavaScript): fetch with integrity check using the Fetch API. Service workers: verify hashes in SW logic. If content truly dynamic (user-generated, personalized), SRI not applicable - use other security measures (CSP, input sanitization). This tool generates hashes for static resources, the primary SRI use case.
SRI and CSP are complementary security mechanisms. CSP: defines which domains can load resources (script-src, style-src). SRI: verifies resource content has not changed. Together: CSP allows cdn.example.com, SRI verifies specific file hash. Example: CSP header Content-Security-Policy: script-src 'self' https://cdn.example.com, HTML: <script src="https://cdn.example.com/lib.js" integrity="sha384-...">. CSP controls source, SRI controls content. Best practice: use both - CSP prevents unauthorized sources, SRI prevents compromised allowed sources. Modern security: CSP + SRI + HTTPS = layered defense. This tool focuses on SRI hash generation - combine with CSP headers for complete protection.
Browser support: all modern browsers (Chrome 45+, Firefox 43+, Safari 11.1+, Edge 17+). IE 11 doesn't support (ignores integrity attribute). Limitations: HTTPS only (no SRI on HTTP), requires CORS (crossorigin attribute), doesn't work for inline scripts, hash updates needed on file changes, doesn't prevent all attacks (can block if CDN fully compromised). Not a replacement for: code review, dependency scanning, CSP, regular security updates. Best for: third-party CDN resources, static assets, public libraries. Performance: minimal overhead (hash verification is fast). Fallback: older browsers ignore integrity attribute gracefully, still load resource. This tool generates cross-browser compatible SRI hashes following W3C standard.