SHA-256 vs SHA-384 vs SHA-512 for SRI

Part of Understanding Cryptographic Hash Algorithms for SRI, this page is a decision guide: it helps you pick which of the three SRI-supported algorithms to standardize on, based on collision resistance, token length, compliance, and performance rather than on how to run the hashing commands.

Quick Reference

Standardize on SHA-384. Reach for SHA-512 only when a policy mandates the maximum digest, and drop to SHA-256 only when a legacy system cannot store the longer token.

How the three algorithms actually differ

All three are members of the SHA-2 family defined in FIPS 180-4, and every current browser engine accepts all three in an integrity attribute. The security-relevant number is collision resistance, which is half the digest size: 128-bit for SHA-256, 192-bit for SHA-384, 256-bit for SHA-512. Even the weakest of these is astronomically beyond any collision attack demonstrated against a web asset, so for SRI the choice is dominated by two practical factors — token length and CPU cost — rather than by a real security gap.

The counter-intuitive detail is that SHA-384 is not slower than SHA-256. SHA-384 is a truncated variant of SHA-512, and both operate on 64-bit words, so on any modern 64-bit CPU they run at essentially the same speed — often faster than the 32-bit-word SHA-256. That is why the W3C recommends SHA-384 as the SRI baseline: you get 192-bit resistance and a shorter token than SHA-512 at no performance penalty. The step-by-step commands for producing these tokens live in How to Calculate SHA-256 vs SHA-384 for SRI; this page is about which one to commit to.

Canonical Comparison

To make an evidence-based choice, generate all three tokens for the exact bytes you will ship and compare them side by side. SHA-384 is the token you place in the tag; the other two are for the decision record.

# Produce all three SRI tokens for the served artifact
for algo in sha256 sha384 sha512; do
  printf '%s-' "$algo"
  openssl dgst -"$algo" -binary lib.min.js | openssl base64 -A
  echo
done

Expected output — note how the token grows with the digest size:

sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC
sha512-z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXcg/SpIdNs6c5H0NE8XYXysP+DGNKHfuwvY7kxvUdBeoGlODJ6+SfaPg==

The SHA-384 token is the one to deploy by default:

<script
  src="https://cdn.example.com/lib.min.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"></script>

Variant Examples

Multi-algorithm attribute for a rolling upgrade

If you are migrating an existing SHA-256 deployment to SHA-384, list both tokens. The browser evaluates only the strongest algorithm it supports and ignores the weaker one — this is a transition aid, not a requirement that both match:

<script
  src="https://cdn.example.com/lib.min.js"
  integrity="sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"></script>

Choosing per compliance regime

Match the algorithm to the strictest control you must satisfy. All three are NIST SP 800-131A approved, so the decision is about internal policy and payment-page scope:

General web assets ............... SHA-384 (W3C recommended default)
PCI DSS v4.0.1 payment pages ..... SHA-384 minimum; SHA-512 if policy mandates max digest
Legacy tooling / tight budgets ... SHA-256 (shortest token, still approved)
FIPS high-assurance systems ...... SHA-512 (256-bit resistance, longest token)

Enforcing a single algorithm in the build

Pin your build tooling to one algorithm so tokens never drift between assets. For example, with the Webpack plugin:

// webpack.config.js — emit only sha384 tokens
import { SubresourceIntegrityPlugin } from 'webpack-subresource-integrity';

export default {
  output: { crossOriginLoading: 'anonymous' },
  plugins: [
    new SubresourceIntegrityPlugin({ hashFuncNames: ['sha384'] }),
  ],
};

Gotchas and Edge Cases

• A longer hash is not meaningfully “more secure” for SRI. The jump from SHA-256’s 128-bit to SHA-512’s 256-bit collision resistance has no practical bearing on web-asset tampering, which relies on a preimage the attacker cannot compute at any of these sizes. Choose on token length and compliance, not on a false sense that bigger is safer.

• SHA-224 and SHA-1 are not valid SRI algorithms. Only sha256, sha384, and sha512 are accepted. A token prefixed with anything else — including sha1 — is treated as an unrecognized digest and the browser reports that it could not find a valid digest, blocking the resource.

• Always add crossorigin="anonymous" regardless of algorithm. The algorithm choice is irrelevant if the attribute is missing: without it the browser issues a no-CORS request, receives an opaque response it cannot read, and blocks the resource before any hash is compared. This omission is the most common SRI failure and is unrelated to which SHA variant you picked.

• Do not mix algorithms across a single asset’s history expecting AND semantics. Multiple space-separated tokens are OR-with-strongest-wins, never AND. Listing sha256-… and sha384-… does not force the browser to verify both.

• Token length changes your CSP hash source too. If you also pin the script in a Content-Security-Policy script-src hash source, that hash must use the same algorithm and value; switching from SHA-256 to SHA-384 means updating both the integrity attribute and the CSP source.

Verification Steps

1. Confirm the deployed token uses your chosen algorithm

grep -oE 'integrity="sha(256|384|512)-[^"]+"' dist/index.html | sort -u

Expected output when standardized on SHA-384 (values differ per asset):

integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"

Any sha256- or sha512- line here flags an asset that drifted from your standard.

2. Re-derive the token from the served bytes

curl -sL https://cdn.example.com/lib.min.js | openssl dgst -sha384 -binary | openssl base64 -A

The output must match the sha384- token in your HTML character-for-character.

3. Confirm clean validation in the browser

Load the page with DevTools open. A mismatched or unsupported algorithm produces this exact console error:

Failed to find a valid digest in the 'integrity' attribute for resource
'https://cdn.example.com/lib.min.js' with computed SHA-384 integrity
'sha384-…'. The resource has been blocked.

No message and a 200 OK in the Network tab confirms the algorithm and token are correct.

Related

• How to Calculate SHA-256 vs SHA-384 for SRI — the step-by-step commands for generating each token via CLI, Node.js, Python, and build tooling
• Understanding Cryptographic Hash Algorithms for SRI — parent page covering the mathematical foundations and NIST compliance mapping for SRI hashing
• Browser Enforcement & Security Boundaries — how the browser computes and compares the digest you chose, including opaque-response handling