SRI Hash Generator

About the SRI Hash Generator

Subresource Integrity (SRI) lets a page say exactly which file it expects from a CDN or another server: the integrity attribute carries a hash of the file, and the browser refuses to run a script or apply a stylesheet whose bytes do not match. If the CDN is hacked or the file changes, the browser blocks the changed file instead of running it.

Drop your scripts and stylesheets here (or paste the code) and the page computes their SHA-256, SHA-384 or SHA-512 digests in your browser and writes the <script> and <link> tags with integrity and crossorigin, for one file or many at once. To check a tag you already have, paste its integrity value: the page applies the specification’s rules — only the strongest algorithm counts, the base64 text must match exactly, unsupported algorithms check nothing — says whether the file would load, and points out a value that browsers read differently.

Without a pass the result is a free preview: the first lines of the tags, the first integrity values and the first checks (a single file shows its verdict with its value hidden). Every value and tag, and copying or downloading them, unlock with a Pro pass.

Common uses

• Pinning jQuery, Bootstrap, fonts’ CSS or analytics scripts loaded from a public CDN, so a compromised CDN cannot run code on your site.
• Adding integrity to the script tags your build or CMS writes, for files you host on a separate static domain.
• Finding out why a browser blocks a script with an “integrity” error in the console.
• Checking that a vendor’s published SRI value belongs to the file you actually downloaded.

How browsers check integrity

• Algorithms. Browsers must support sha256, sha384 and sha512. MD5 and SHA-1 are not accepted; a value with only those checks nothing.
• Strongest wins. With several values, the browser uses only those of the strongest algorithm listed, and the file passes if any of them matches. A matching weaker value does not help.
• Exact bytes. The digest is of the file as the browser receives it (after any compression is undone), so a re-minified file, another version on the same URL, CRLF instead of LF line ends or a byte-order mark all break it. Hash the file you serve, not a copy you edited.
• Exact text. The specification compares the base64 value as written: standard base64 with its = padding, and the algorithm in lower case. Browsers are not all that strict: Chromium-based ones also read URL-safe characters (-, _) but ignore an algorithm name in capitals (and then check nothing), so a value written another way can load in one browser and fail in another.
• CORS. A file from another origin is checked only if it is fetched with CORS: add crossorigin="anonymous" and make sure the server sends Access-Control-Allow-Origin. Without CORS the file is blocked.
• Failure. A file that fails is not executed or applied, the request ends as a network error and the element fires an error event, which you can use to load a fallback copy.

Source: W3C Subresource Integrity.

Integrity and your Content Security Policy

SRI and CSP work together: a policy decides which hosts may serve scripts, integrity decides which exact files. A strict CSP can also allow a script by its hash (script-src 'sha384-…') — the same kind of digest this page computes. Build a policy with the CSP Generator, and check the headers of your page with the Security Headers Checker.

Limitations

• Nothing is downloaded from a URL: open or download the file from your CDN and drop it here. Pasted code is hashed as UTF-8 with the line ends you choose, which must be the bytes the server sends.
• The SRI specification covers scripts and stylesheets (and their preloads); images, fonts and frames have no integrity attribute.
• A file that changes on every request (an analytics script without a version in its URL) cannot be pinned: its next version will be blocked.

Privacy

On this device: nothing is sent

Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.