SRI Attribute Generator — Calculate SHA-384 for Assets

A subresource integrity generator calculates a cryptographic SHA-384 digest from the exact bytes of a JavaScript or CSS asset and formats it as an integrity attribute. Upload the asset, paste its exact UTF-8 text, or explicitly fetch an HTTPS resource that permits cross-origin browser access. The tool computes the digest using Web Crypto and can produce an example script or stylesheet tag with the resulting integrity string. It does not predict CDN contents, hash a URL label, or report success when a remote request fails. SRI only works when the integrity value matches the asset actually delivered to the browser.

Subresource Integrity Generator At a Glance

Why Subresource Integrity Exists

Subresource Integrity is a browser feature designed to help site owners detect when a referenced script or stylesheet differs from an expected, known version. The page supplies a cryptographic digest in an integrity attribute, and the browser compares the delivered bytes with that digest before using the resource. It is especially relevant when a site loads dependencies from third-party delivery networks, where content may change independently of the site's own HTML. SRI does not make a malicious resource trustworthy merely because it has a hash. The expected bytes must come from a reviewed and trusted build or release, and the integrity value must be updated intentionally when that trusted asset changes.

What SHA-384 Measures

SHA-384 transforms a sequence of bytes into a fixed-length 384-bit digest. In an SRI attribute, that digest is Base64 encoded and prefixed with sha384-. The result describes the exact input bytes, not the human-readable filename, MIME type, or visible appearance of a stylesheet. Two scripts that look identical in an editor but differ in line endings, character encoding, a source-map comment, or minification output will usually have different hashes. This precision is the point of the protection: a browser should reject changes that were not included in the expected integrity value, whether those changes are malicious or accidental.

Choosing Local File, Text, or Public URL Input

The safest input is often a copy of the exact compiled asset file that will be deployed. A local file is read as binary data, preserving its bytes without decoding and re-encoding. Pasted source is encoded as UTF-8 before hashing, which is appropriate only if those bytes match the eventual served content exactly. URL mode performs an explicit HTTPS fetch from the browser and hashes only a completed, successful response. It does not use the page-inspection PHP endpoint or bypass cross-origin controls. If the remote server does not allow that fetch, the tool shows an error and the user can supply the independently obtained file instead.

How to Generate an Attribute From a Real Asset

For a local JavaScript file, choose the file option and select the exact build output. The generator reads the file bytes, computes SHA-384 through Web Crypto, and returns an integrity string that begins with sha384-. Enter the HTTPS location at which the file will be served to obtain an example script tag containing the src, integrity, and crossorigin attributes. The location is not used to change or recalculate the local hash. After deployment, check that the server actually returns the same build file and that any edge optimizer, compressor, or rewrite system does not alter the content before browser integrity validation.

Why Cross-Origin Resources Need Careful CORS Settings

Browsers apply cross-origin rules when using SRI on assets hosted at another origin. A crossorigin attribute can influence the request mode and credentials behavior, and the resource server may need an appropriate Access-Control-Allow-Origin response. This means that a correct hash can coexist with a blocked resource if cross-origin response requirements are not satisfied. The generated example uses an anonymous cross-origin setting as a generally appropriate starting point for public resources, but actual deployment behavior depends on the remote host and your application's requirements. Validate the result in the browser network panel and do not treat a successful local digest calculation as proof that a third-party origin is configured correctly.

Static Assets and Versioning

A stable, versioned asset path makes integrity management easier because the page and resource can be deployed as an intentional pair. If a build process produces a new file with a different digest, the corresponding HTML attribute must change at the same time. Unversioned CDN URLs that silently deliver new JavaScript are poor candidates for a fixed hash unless the site owner controls updates and understands the risk of mismatches. Some CDNs offer explicit immutable version paths; others rewrite scripts based on query parameters or optimization settings. Always hash the final representation that browsers actually request, not an earlier development copy that may be transformed during publishing.

Example: Securing a Stylesheet Reference

Suppose an interface uses an external stylesheet hosted at https://cdn.example.com/design-v3.css. Obtain the precise file that will be served, calculate its hash, and generate an example link tag with rel set to stylesheet, href set to the HTTPS resource, and the integrity value attached. On deployment, open the page in a browser and confirm that the stylesheet loads without an integrity mismatch or cross-origin error. If the stylesheet later changes even by one whitespace character, the old hash must no longer match. The correct response is to review and deliberately update the asset and hash together rather than removing SRI silently to hide the failure.

Understanding Errors and Byte Limits

The generator rejects empty inputs and files larger than eight mebibytes, keeping calculations bounded and export behavior predictable. URL mode checks for HTTPS and rejects embedded URL credentials, requires a successful response, and limits streamed response bytes rather than trusting a potentially incorrect Content-Length header. A failed request produces no integrity value. This distinction matters because a fabricated or partial digest could be copied into production and then break the resource load. If the browser does not provide a secure Web Crypto context, hashing also fails explicitly. Use a secure deployment origin and an up-to-date browser for the calculation.

What SRI Does Not Protect

SRI checks the contents of a particular referenced resource; it does not validate the semantic correctness of that code, the security of its dependencies, or the integrity of every request the script initiates. A compromised website that changes both its HTML and hash can bypass the intended guarantee, while an already malicious dependency will still match a hash calculated from malicious bytes. Use dependency review, controlled build pipelines, HTTPS delivery, CSP, and runtime monitoring as complementary controls. A text hash generator can compare specific text strings, but SRI requires the exact asset bytes and the prescribed integrity format rather than a general checksum label.

Final Deployment Check for SHA-384 Attributes

After adding the attribute, reload the real page with developer tools open and watch for integrity, content-security, cross-origin, or network errors. Confirm that the requested script or stylesheet is the intended version, appears only where needed, and is delivered without unexpected transformations. Store the hash with build metadata so a later deployment can explain why it changed. For third-party resources, document the trusted release source and update procedure. An SRI calculation is a precise cryptographic building block, but a dependable production integration requires matching bytes, correct markup, compatible CORS behavior, and deliberate release management.

Build Reproducibility and Release Tracking

Teams that generate hashed assets through a build pipeline should keep the build version, dependency lockfile, artifact checksum, and deployed URL aligned. A late content rewrite performed by a CDN, edge worker, plugin, or packaging step can invalidate an SRI attribute even when a developer calculated the original hash correctly. For that reason, the most dependable point to calculate integrity is after all intended transformations and before deployment, using immutable output files. Treat the generated string as a property of one particular artifact, not as a permanent property of a library name. When reviewing a deployment, compare the response body obtained from the serving origin with the asset used for hashing and investigate differences in encoding or build settings. If a mismatch is discovered, do not automatically remove integrity protection; determine which file is trusted and deploy the corresponding reference and hash together.

Frequently Asked Questions About Subresource Integrity Generator