v149 · CSS · Security

SRI Debugger

Sub-resource Integrity for CSS url() works exactly like SRI for <script> and <link>, but the hash must match the raw response bytes. This tool computes the correct hash for any text content, compares it to a value you provide, and shows you exactly what a browser checks before accepting or rejecting the resource.

Failure scenarios

Hash matches

Content and hash are in sync — SRI passes, resource loads

Hash mismatch

Content changed after hash was generated — SRI blocks load

Wrong algorithm prefix

Hash is valid sha256 but integrity string says sha384

Truncated hash

Hash value is correct but cut short — length check fails

Resource content + expected integrity
// Computed hash will appear here

What SRI checks

The browser fetches the resource, hashes the raw response body, and compares it to the declared integrity value. If they don't match, the resource is blocked — even if the server said 200 OK.

CSS url() integrity syntax

Inside a CSS url() call: url("myfont.woff2" integrity("sha256-abc123")). The algorithm prefix (sha256-, sha384-, sha512-) must match the algorithm used to generate the hash.

Common failure causes

Gzip/brotli encoding changes the bytes after the hash was computed (use uncompressed bytes). CDN whitespace normalisation. Charset re-encoding. Server-side minification after deployment.

Difference from <script> / <link> SRI

The mechanics are identical. The difference is location: HTML SRI sits on the element attribute; CSS SRI sits inside the url() call. Both end up as the same fetch-level integrity check.

see also