Skip to main content
Yoryantra
Home/Tools
← Back to Tools

Subresource Integrity Hash Generator

Generate SRI from UTF-8 resource text represented in the browser and produce deployable integrity attributes.

Hashing uses the UTF-8 bytes represented by this browser textarea. The page does not trim or Unicode-normalize the value, but textarea line breaks are represented as LF. If the deployed file uses CRLF, a BOM, non-UTF-8 bytes, or other byte-level differences, hash the actual file bytes instead.

Optional for an integrity value alone. A URL is required when you ask for a complete script or stylesheet tag.

Choose the SRI output

SHA-256, SHA-384, and SHA-512 are valid SRI algorithms. The SRI specification describes SHA-384 as a good baseline; if different algorithms are combined, the browser evaluates the strongest supported algorithm present.

Output

Generated SRI output will appear here.
Hashing happens in this browser with Web Crypto. The pasted resource text is not fetched, uploaded, or compared with the URL automatically.

SRI protects a particular resource body, not a CDN name

An integrity attribute tells the browser which cryptographic digest is acceptable for a script or stylesheet. If the fetched bytes do not match the strongest supported integrity metadata, the browser refuses to use that resource.

That protects against an unexpected file replacement at a third-party host, but only when the hash was created from the exact version you intended to trust.

Copying source text can change the bytes you meant to hash

Minification, a trailing newline, CRLF versus LF, Unicode normalization, or a build step that rewrites text will change the digest. For a production CDN file, generating SRI from the exact downloaded artifact is safer than copying code from an editor or documentation page.

This page hashes UTF-8 text because that is what a browser textarea can represent. It is not a byte-for-byte file upload hasher for arbitrary binary content or non-UTF-8 source files.

Combining SHA-256, SHA-384, and SHA-512 is not ordinary fallback

An integrity attribute may contain several space-separated hashes. When different supported algorithms are present, the browser selects the strongest algorithm set and ignores weaker ones for that response. Multiple hashes of the same strongest algorithm can represent approved alternate resource bodies.

Cross-origin SRI needs CORS cooperation

A resource on another origin must be fetched with CORS for SRI validation. In ordinary script and stylesheet markup that normally means a crossorigin="anonymous" attribute and an appropriate Access-Control-Allow-Origin response from the resource server.

A correct hash cannot compensate for missing CORS permission. If the CDN does not opt in, the cross-origin resource still fails.

Pin the URL and update the hash together

URLs such as latest.js or an unversioned package path can change without notice. SRI then turns that change into a load failure, which is safer than executing unexpected code but can still break the page. Versioned resource URLs make that failure mode easier to control.

Standards behind the integrity attribute

The W3C Subresource Integrity specification defines the integrity metadata format, algorithm priority, and CORS requirement. The HTML specification applies the attribute to scripts and qualifying link resources, including stylesheets.

References: W3C Subresource Integrity and MDN Subresource Integrity.