BYTETOOLS

SRI Hash Generator

Generate a Subresource Integrity hash for any script or stylesheet and get a ready-to-paste integrity attribute with the crossorigin setting.

Drop the exact file you will serve (.js, .css, …)Hashed locally with Web Crypto — the file is never uploaded

What is the SRI Hash Generator?

Subresource Integrity lets a browser verify that a file fetched from a CDN has not been altered. The integrity attribute holds a Base64-encoded SHA-256, SHA-384 or SHA-512 hash of the exact file bytes.

  • SHA-256, SHA-384 and SHA-512 digests computed with Web Crypto
  • Complete script or link tag with integrity and crossorigin already set
  • Multiple space-separated hashes for fallback across browsers
  • Works from a dropped file or pasted source text
  • URL is HTML-escaped so the generated tag is always safe to paste
  • Entirely local — your file is never uploaded to any server

How to use the SRI Hash Generator

  1. 1

    Drop the exact file you will serve, or paste its contents and click Hash pasted code.

  2. 2

    Choose the primary algorithm — SHA-384 is the usual recommendation.

  3. 3

    Tick sha256 or sha512 if you also want fallback hashes in the same attribute.

  4. 4

    Pick whether the tag is a script or a stylesheet and enter the resource URL.

  5. 5

    Copy the integrity attribute, or the whole ready-to-paste HTML tag.

About the SRI Hash Generator

When you load a script from a CDN you are trusting that CDN completely. Subresource Integrity closes that gap: the browser hashes the file it receives and refuses to execute it unless the hash matches the one in your integrity attribute. This tool computes that hash from the exact bytes of your file.

Drop the file you will actually serve, or paste its contents, and you get SHA-256, SHA-384 and SHA-512 digests along with a complete script or link tag including the crossorigin attribute that SRI requires. You can add fallback hashes for older browsers, in which case the browser uses the strongest algorithm it understands.

Hashing uses the Web Crypto API and happens entirely in your browser — the file is never uploaded. Because the hash covers the exact bytes, dropping the real file is always safer than pasting its text: a single added or missing trailing newline produces a completely different hash and a resource that silently refuses to load.

Frequently asked questions

What is Subresource Integrity and why should I use it?

It is a browser feature that verifies a fetched file against a hash you specify. If a CDN is compromised or a file is modified in transit, the hash will not match and the browser refuses to run it — turning a silent supply-chain attack into a visible load failure.

Which hash algorithm should I use for SRI?

SHA-384 is the common recommendation and what most CDN documentation shows. SHA-256 is equally acceptable and produces a shorter attribute. All three supported algorithms are cryptographically sound for this purpose; the choice is mostly convention.

Why does my resource fail to load after adding integrity?

Two usual causes: the file changed after you generated the hash, or the response lacks the CORS headers that SRI requires. You need crossorigin="anonymous" on the tag and Access-Control-Allow-Origin on the response — SRI only applies to CORS-enabled cross-origin loads.

Can I use SRI on a file I host myself?

You can, but it adds little. SRI protects against a third party altering a file you do not control. For same-origin files an attacker who can change the file can usually change the HTML that references it too.

Do multiple hashes make my page more secure?

No — they are a compatibility fallback. The browser picks the strongest algorithm it supports and the resource loads if any single listed hash matches. Include several only if you need to support browsers with different algorithm support.

Related tools