MiniUtil field guide

Why a Subresource Integrity Hash Fails

Diagnose Subresource Integrity failures: changed CDN bytes, a missing crossorigin attribute, algorithm selection, and hashing the wrong build.

Short answer: An integrity failure almost always means the delivered bytes changed, the cross-origin request was never allowed to be checked, or the hash came from a different build than the one the browser fetched.

Integrity pins bytes, not versions

The browser hashes the resource it actually received and compares the result against the values in the integrity attribute. If the digest does not match at least one listed value, the resource is treated as a network error and is neither executed nor applied. Any change to the content breaks the match, including a re-minified build, an added banner comment, or a trailing newline.

A cross-origin resource needs CORS as well

Integrity on a cross-origin resource requires the crossorigin attribute and a server that returns a permissive Access-Control-Allow-Origin header. Without the attribute the request is made in no-cors mode and the browser blocks it outright rather than checking the hash, because comparing digests against an opaque response would let a page probe its contents.

  • Add crossorigin="anonymous" to cross-origin script and link elements.
  • Confirm the CDN returns an Access-Control-Allow-Origin header.
  • A blocked request with no integrity message usually means the attribute is missing.

The strongest listed algorithm is the one that decides

SRI accepts sha256, sha384, and sha512. When several algorithms appear in the same attribute, the browser picks the strongest one present and validates against those values only. A correct sha256 sitting next to an outdated sha384 still fails, because the sha384 entries are the ones being checked.

Pin only URLs that cannot change

Integrity and mutable URLs are incompatible by design. A URL that always serves the newest release will break the page the moment the release changes, and the failure appears as a site outage rather than a dependency update. Pin an immutable versioned URL, or host the asset yourself and generate the hash as part of the build.

Reading an SRI failure

SymptomLikely causeFix
Console reports an integrity mismatchThe file at that URL changedRegenerate the hash from the exact bytes now being served
Request blocked before any hash is reportedMissing crossorigin attribute on a cross-origin resourceAdd crossorigin and allow the origin with CORS
Works from a local copy, fails from the CDNThe CDN transforms, re-minifies, or rewrites the assetPin an immutable version or self-host the file
One listed hash is correct but the load still failsA stronger listed algorithm is being validated insteadMake every listed hash describe the same bytes