Subresource Integrity Hash Calculator
Generate SRI hashes for scripts and styles, protect against unexpected third-party file changes, and validate cross-origin requirements.
Calculator
Results
Introduction
Subresource Integrity helps browsers verify that third-party scripts and stylesheets have not been unexpectedly modified. If the file contents change, the browser can refuse to load the resource.
This tool calculates the required hash values and generates the corresponding integrity attributes.
How it works
The tool hashes resource content using the browser’s Web Crypto API. You can paste content directly for local processing, or fetch a URL from your browser when CORS allows.
- Pasted content is hashed locally.
- Fetched resources are requested directly by your browser.
- Hashes are encoded as base64.
- The generated tag includes the selected crossorigin behavior.
How to use
- Select whether the resource is a script or stylesheet.
- Choose SHA-256, SHA-384, or SHA-512.
- Paste the exact resource content, or provide a URL to fetch.
- Calculate the hash.
- Copy the integrity value or full HTML tag.
- Test the resource in staging before production deployment.
Practical example
A script tag with SRI may look like this:
<script
src="https://cdn.example.com/library.js"
integrity="sha384-EXAMPLEHASH"
crossorigin="anonymous">
</script>If the CDN later serves a different file, the browser will block the resource because the hash no longer matches.
Use cases
- Securing CDN-hosted JavaScript libraries.
- Protecting third-party CSS dependencies.
- Auditing external resources before launch.
- Generating integrity attributes for templated assets.
- Reviewing cross-origin loading requirements.
Best practices
- Use SHA-384 or SHA-512 for stronger integrity protection.
- Generate hashes from the exact deployed file.
- Use
crossorigin="anonymous"for cross-origin resources when appropriate. - Ensure the server sends correct CORS headers for cross-origin resources.
- Automate hash generation in deployment pipelines when possible.
Common mistakes
- Hashing a local development file that differs from production.
- Forgetting that compression or CDN transformations can change bytes.
- Using SRI on resources that change frequently without updating hashes.
- Omitting the crossorigin attribute for cross-origin resources.
- Assuming SRI replaces HTTPS or secure supply-chain practices.
Limitations
- The fetch option depends on the remote server allowing CORS.
- Pasted text may not match exact file bytes.
- Some CDNs may transform files based on request headers.
- The tool does not monitor remote resources over time.
Browser compatibility
Subresource Integrity is supported by current major browsers. Web Crypto hash generation requires a secure context such as HTTPS or localhost.
FAQ
Is my resource uploaded to ClientSideTools?
No. Pasted content is hashed locally. Optional fetch requests come from your browser.
Why did my hash stop matching after deployment?
The deployed file may differ due to minification, line endings, encoding, compression, or CDN transformations. Regenerate the hash from the exact deployed bytes.
Do I need crossorigin for same-origin resources?
Usually no. Crossorigin is mainly important for cross-origin resources where CORS response headers are required.
Which algorithm should I use?
SHA-384 is a common default. SHA-512 provides stronger hashing, while SHA-256 is widely supported but shorter.