About this tool
Create deployment-ready integrity attributes for public scripts and stylesheets while keeping byte scope and runtime checks explicit.
SRI Generator & Verifier produces the integrity attribute a browser uses to confirm a script or stylesheet has not been altered between your build and the visitor's page. You select the exact file you will deploy, up to 100 MB, and the tool hashes its bytes with Web Crypto using SHA-256, SHA-384, SHA-512, or all three, then formats the result as sha384-style tokens ready for HTML. A second field lets you paste integrity metadata you already have, such as the value from an existing tag or a CDN's documentation, and the tool checks it against the fresh digest following the W3C rule that only the strongest supported algorithm present counts. It also writes the finished script or link element and a JSON summary.
- Hashes the exact selected bytes with Web Crypto SHA-256, SHA-384, SHA-512, or all three under a 100 MB file limit.
- Parses bounded multi-token metadata and applies the W3C strongest-supported-algorithm set rule rather than comparing the entire string literally.
- Creates escaped script or stylesheet markup and versioned JSON evidence while separating local byte verification from deployment, CORS, HTTPS, and browser-load checks.
How to use SRI Generator
Choose or drop the public asset onto the file area. Under Primary algorithm pick SHA-256, SHA-384, or SHA-512, or tick Generate SHA-256, SHA-384, and SHA-512 to emit all three tokens separated by spaces. Click Generate integrity metadata; the digest appears in the Generated integrity box. To verify an existing value, paste it into Expected integrity metadata. Tokens are parsed individually, so a mix like sha384-... sha512-... is handled, and the badge row counts valid, invalid, and unsupported tokens. Finally set HTML element to Script or Stylesheet link, type the Resource URL or path, and copy the HTML snippet, which already includes crossorigin="anonymous". Download JSON saves the digests, verification result, and snippet together.
When this tool is useful
- A front-end developer adds integrity attributes to third-party scripts loaded from a CDN before a security review.
- A release engineer confirms that the minified bundle in the artifact store matches the hash committed in the HTML template.
- A web agency audits an inherited site whose tags carry sha256 tokens and needs to know whether they still match the files.
- A library maintainer publishes SRI hashes alongside a new version so downstream users can pin the exact release.
- A security analyst checks a downloaded vendor stylesheet against the integrity value quoted in the vendor's documentation.
Practical tips
- Hash the file exactly as it will be served, after minification and any build transforms; a single changed byte produces a completely different digest.
- When multiple tokens are present, only the strongest algorithm decides the outcome. A matching sha256 token does not rescue a mismatching sha384 one.
- Base64url variants using - and _ are accepted in the expected field, but the generated tokens use standard Base64, which is what browsers expect.
- Nothing here fetches the URL. Confirm separately that the CDN sends a CORS header, because without it the browser blocks an integrity-checked cross-origin load.
- Prefer versioned, immutable asset URLs. Pointing an integrity attribute at a latest alias means the page breaks the moment upstream publishes a new build.
Examples you can test
Load an example, compare the result with the expected output, then replace it with your own input.
Generate a tag for a vendored script
Example input
vendor-4.2.0.min.js, 142 KB; Primary algorithm SHA-384; element Script; path /assets/vendor-4.2.0.min.js
Expected output
A sha384- token followed by the Base64 digest, and a script tag with src, integrity, and crossorigin="anonymous"
The digest is 48 bytes, so the Base64 portion is always 64 characters long; a different length means the token was truncated somewhere.
Check a CDN's published hash
Example input
Downloaded framework.css and the expected string sha256-abc... sha512-xyz... copied from the CDN page
Expected output
Match or mismatch reported against the sha512 token, with sha256 counted as valid but not decisive
If you only generated SHA-384, the tool asks you to generate SHA-512 first because that is the strongest algorithm in the pasted metadata.
Validation checklist
- Confirm the selected file is the deployed build, not a source or map file.
- Check the algorithm prefix in the snippet matches the one you intended to ship.
- Load the final tag in a test page and watch the console for integrity errors.
- Confirm the CDN or host returns Access-Control-Allow-Origin for the resource.
- Regenerate and update the tag every time the asset is rebuilt.