Subresource Integrity Calculator

Subresource Integrity (SRI) is a security feature that enables browsers to verify that files they fetch (like JavaScript or CSS) are delivered without unexpected manipulation. This calculator helps you generate and verify SRI hashes for your web resources.

What is Subresource Integrity?

Subresource Integrity (SRI) is a security mechanism that allows web developers to ensure that resources they load (such as JavaScript files, CSS files, or web fonts) have not been tampered with. It works by requiring the browser to verify the integrity of these resources using cryptographic hashes.

SRI is particularly important for loading third-party resources where you can't control the content delivery. It helps prevent attacks where malicious actors might inject harmful code into these resources.

Why Use Subresource Integrity?

Using SRI provides several benefits:

Prevents man-in-the-middle attacks by verifying resource integrity
Ensures resources haven't been modified after being cached
Provides an additional layer of security for critical resources
Helps meet security requirements for compliance standards

How to Use This Calculator

This calculator allows you to:

Enter the content of your resource (JavaScript, CSS, or other text-based content)
Select the hash algorithm (SHA-256, SHA-384, or SHA-512)
Generate the integrity hash for your resource
Verify existing hashes against your content

The calculator uses the Web Crypto API to generate cryptographic hashes of your input content. The formula is:

hash = await crypto.subtle.digest(algorithm, content)

The result is then encoded as a base64 string.

Example Usage

If you have a JavaScript file with the content:

console.log("Hello, world!");

Using SHA-256, the calculator would generate a hash that looks like:

sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=

You would then include this in your HTML like this:

<script src="example.js" integrity="sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=" crossorigin="anonymous"></script>

How Subresource Integrity Works

The SRI process involves these key steps:

Generate a cryptographic hash of your resource file
Encode the hash in base64
Add the integrity attribute to your HTML element
The browser verifies the hash when loading the resource

Supported Hash Algorithms

SRI supports several hash algorithms, each with different security characteristics:

Algorithm	Output Size (bits)	Security Level
SHA-256	256	Good for most use cases
SHA-384	384	Higher security, slightly slower
SHA-512	512	Highest security, slowest

For most web applications, SHA-256 provides a good balance between security and performance. The higher-bit algorithms are only necessary for very sensitive applications.

Best Practices for SRI

When implementing SRI, consider these best practices:

Always use HTTPS to ensure resources are delivered securely
Include the crossorigin attribute when loading external resources
Test your SRI implementation in multiple browsers
Consider using a Content Security Policy (CSP) alongside SRI
Regularly update your resource hashes when they change

Common Pitfalls

Avoid these common mistakes when working with SRI:

Not including the crossorigin attribute when loading external resources
Using HTTP instead of HTTPS for resource delivery
Not updating hashes when resources change
Using weak hash algorithms for sensitive resources
Not testing your implementation in multiple browsers

Frequently Asked Questions

What browsers support Subresource Integrity?

All modern browsers support SRI, including Chrome, Firefox, Safari, Edge, and Opera. Internet Explorer does not support SRI.

Can I use SRI with inline scripts or styles?

No, SRI only works with external resources. For inline scripts and styles, you should use a Content Security Policy (CSP) instead.

How often should I update my resource hashes?

You should update your hashes whenever you modify your resources. For development environments, you might want to disable SRI temporarily.

What happens if a resource fails SRI verification?

The browser will refuse to load the resource and log an error in the console. This prevents potentially malicious code from executing.