The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A correct SRI hash for your local file does not guarantee that a browser will run the script. Subresource Integrity (SRI) checks the bytes in the response the browser fetched, and it may validate only the strongest hash algorithm listed in the integrity attribute. A line-ending change can alter the response bytes; a stale stronger digest can override a correct weaker one.
What SRI verifies
Subresource Integrity lets a browser check that a fetched resource has not been unexpectedly changed before using it. The browser calculates a cryptographic digest from the resource bytes, encodes the digest in Base64, and compares it with the metadata in the element’s integrity attribute. The comparison is case-sensitive. If verification fails, the script is not executed. The W3C Subresource Integrity specification describes the mechanism and its verification algorithm.
The important distinction is between the file you hashed and the response the browser received. Hashing a local source file proves only that the digest matches those local bytes; it does not establish that the deployed response is identical.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsWhy line endings can make a correct hash fail
SRI hashes bytes, not the visual appearance of text. An LF line ending is the byte 0A; a CRLF line ending is the two-byte sequence 0D 0A. If a checkout, build process, deployment pipeline, proxy, or server transformation changes one into the other, the byte stream changes and its digest changes too.
#1 Best Overall
This does not mean a browser necessarily normalizes or mishandles line endings. It means the digest must match the exact bytes in the fetched response. Other byte-level differences can have the same effect: a final newline, a byte-order mark, minification, bundling, an injected banner, a changed asset version, or a transformation of the response.
Hash the response, not a convenient copy
Use the browser’s Network panel to identify the final resource URL and inspect the response actually returned, taking redirects and cache behavior into account. Capture that response without passing it through an editor or other step that might normalize line endings, then calculate the digest using the algorithm named in the relevant integrity entry. Compare the resulting Base64 value character-for-character with the attribute.
How a stronger stale hash overrides a correct one
If an integrity value lists different algorithms, the browser selects metadata for the strongest algorithm present. The specified order, from weaker to stronger, is SHA-256, SHA-384, then SHA-512. A matching digest for a weaker algorithm does not rescue a mismatch at the strongest listed level. The SRI specification defines this selection rule.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #2
For example, the SHA-384 entry below could be correct for the response, but the stale SHA-512 entry means the browser checks the SHA-512 metadata instead:
<script src="/app.js"
integrity="sha384-CORRECT_DIGEST sha512-STALE_OR_INCORRECT_DIGEST"></script>If the attribute contains multiple entries using the strongest algorithm, a match against any of those entries is sufficient. Review all entries at the strongest level when debugging; do not assume that a weaker match is enough. This is especially important when adding a stronger algorithm during a migration, because a stale stronger digest changes which metadata the browser uses.
Rank #3
A practical troubleshooting sequence
- Find the response. In the browser’s Network panel, identify the final URL and inspect the response body the browser received. Check redirects and whether a cached response may be involved.
- Calculate the digest from those bytes. Capture the response without text-editor line-ending conversion and hash it with the algorithm specified in the integrity entry.
- Compare the value exactly. Check the Base64 digest character-for-character. SRI comparisons are case-sensitive.
- Check algorithm selection. List the algorithms in the
integrityattribute, identify the strongest one present, and verify the entries at that level. Remove stale metadata or regenerate the correct stronger entry as needed. - Check other loading errors. Look at the console and Network panel for CORS failures, Content Security Policy restrictions, an incorrect URL or version, or another load error that could be mistaken for an SRI failure.
- Verify cross-origin eligibility and transport security. For a cross-origin resource protected by SRI, the request must satisfy CORS. The specification also recommends using integrity metadata in a Secure Context because metadata delivered over an insecure connection could be altered by a network attacker.
What the standard says—and what it does not establish
The W3C’s SRI Level 2 document surfaced from the current specification report is a Working Draft dated 2026-03-20, not a finalized Recommendation. The specification states that conforming user agents must support SHA-256, SHA-384, and SHA-512. It does not establish the cause of a particular site’s failure or provide a prevalence figure for SRI errors or line-ending mismatches. The browser’s console message, response, and page configuration are needed to diagnose an individual case.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
