SRI Hash Generator

What is Subresource Integrity (SRI)?

Subresource Integrity (SRI) is a security feature that enables browsers to verify that fetched resources (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that the fetched resource must match. If the resource has been altered, the browser refuses to execute it – protecting your site from XSS and data injection attacks.

<script src="https://code.jquery.com/jquery-3.7.1.min.js" 
        integrity="sha384-...generated-hash..." 
        crossorigin="anonymous"></script>

Why Use SRI? — Defence in Depth

• CDN compromise mitigation: Even if a CDN is hacked, the malicious code won't run because the hash won't match.
• Integrity of third‑party libraries: Ensure that the library you intend is exactly what executes.
• Compliance & best practice: Recommended by OWASP, Google, and Mozilla for modern web applications.
• Works with any resource: Stylesheets, scripts, fonts, and even fetch() requests can be protected.

How This Generator Works

Step‑by‑Step Guide

1. Choose an algorithm (default SHA-384).
2. Provide input – either upload a file (switch to "Upload file" tab) or paste content (switch to "Paste content" tab).
3. Click “Generate SRI Hash” – the tool computes the digest instantly from the currently active tab.
4. Copy the integrity string and insert it into your <script> or <link> tag.
5. Always use crossorigin="anonymous" when loading cross‑origin resources with SRI.

Browser Support & Automation

SRI is supported in all modern browsers (Chrome, Firefox, Safari, Edge). For older browsers, the integrity attribute is ignored – the resource loads normally, so there's no breakage. You can easily integrate SRI generation into your build pipeline using tools like webpack-subresource-integrity or by scripting with Node.js crypto. This online tool is perfect for quick one‑off generations or for verifying existing hashes.

Real‑World CDN Examples (Pre‑loaded)

Click any example to load the actual CDN content (the tool will fetch a small sample and automatically switch to the "Paste content" tab). All examples use live HTTPS requests.

* Actual hashes may vary if the CDN updates. Always regenerate for the exact file you reference.

Common Pitfalls & Misconceptions

• SRI only works with same‑origin or CORS‑enabled resources: You must include the crossorigin attribute, and the server must respond with appropriate CORS headers (Access-Control-Allow-Origin).
• Don't mix algorithms: The browser expects exactly one hash per algorithm; you can provide multiple hashes (space‑separated) for fallback, but the format must be consistent.
• SRI is not a replacement for HTTPS: It complements it by adding an extra layer of integrity.
• Hashing is done on the exact bytes: Even a single whitespace change will produce a different hash. That's why minified files are often used.

Combining SRI with Content Security Policy (CSP)

For maximum protection, use SRI together with a strong CSP. For example, you can use the require-sri-for directive (experimental) or simply rely on the fact that if an attacker injects a script, its integrity won't match. A typical CSP header might look like: Content-Security-Policy: script-src https://cdn.example.com 'strict-dynamic';. SRI adds a second layer of verification even if the allowed domain is compromised.

JavaScript Implementation (Web Crypto)

async function generateSRI(algorithm, content) {
  const encoder = new TextEncoder();
  const data = encoder.encode(content);   // for text
  // for file: use FileReader to get ArrayBuffer
  const hashBuffer = await crypto.subtle.digest(algorithm, data);
  const hashArray = Array.from(new Uint8Array(hashBuffer));
  const base64 = btoa(String.fromCharCode(...hashArray));
  return `${algorithm.toLowerCase().replace('-', '')}-${base64}`;
}
                    

SRI & The Modern Web: Best Practices

• Always use SRI for all third‑party static assets (scripts, styles).
• Generate hashes during your build process (automated).
• Combine with a strong Content Security Policy (CSP) that restricts script sources.
• Monitor CDN URLs for updates; when a library version changes, update the hash accordingly.
• Use SHA-384 as a reasonable default – it's widely adopted and secure.

Frequently Asked Questions