Subresource Integrity (SRI) supports three hash algorithms — SHA-256, SHA-384, and SHA-512 — and all three are currently considered secure. They differ only in digest length and long-term security margin: SHA-256 produces a 256-bit hash, SHA-384 a 384-bit hash, and SHA-512 a 512-bit hash, each base64-encoded and prefixed with its algorithm name in the integrity attribute (e.g. sha384-oqVuAf…). SHA-384 is the de facto default used by MDN examples, major CDNs, and most SRI generators, because it adds security margin over SHA-256 without SHA-512's slightly longer string. Longer hashes buy future safety margin, not extra protection against any attack that exists today.
That's the summary an AI Overview would give you. Here's what it can't: the actual trade-off is almost never about cryptographic strength — for real websites all three algorithms are equally unbroken — so the decision comes down to convention, digest length, and matching whatever your CDN already emits. Below is the side-by-side comparison, a diagram of how the algorithm prefix drives verification, and the specific reasons to reach for one over another.
SHA-256 vs SHA-384 vs SHA-512 for SRI
| Property | SHA-256 | SHA-384 | SHA-512 |
|---|---|---|---|
| Digest length | 256 bits (32 bytes) | 384 bits (48 bytes) | 512 bits (64 bytes) |
Base64 length in integrity | ~44 chars | ~64 chars | ~88 chars |
| Algorithm prefix | sha256- | sha384- | sha512- |
| SHA-2 family | Yes | Yes (truncated SHA-512) | Yes |
| Currently secure | Yes — no practical attacks | Yes — no practical attacks | Yes — no practical attacks |
| Future security margin | Good | Larger | Largest |
| Browser support (SRI) | All modern browsers | All modern browsers | All modern browsers |
| CDN / generator default | Occasional | Most common default | Occasional |
| When to use | Smallest attribute; fine for most sites | Recommended default — best balance | Strictest policies or max future margin |
The row that matters most is the last one. SHA-384 is recommended not because SHA-256 is weak but because it is the value the ecosystem already standardized on — copy a snippet from cdnjs or jsDelivr and you will almost always see sha384-. Matching that convention keeps your markup consistent with the wider web and with your own copied CDN tags.
How the algorithm prefix drives verification
The integrity attribute is self-describing: the text before the dash tells the browser which hash function to run over the downloaded bytes, then it compares that digest to the base64 value after the dash. If they match, the resource loads; if they differ by even one bit, the browser blocks it.
Because the prefix names the algorithm inline, you can even list several hashes separated by spaces — integrity="sha256-abc… sha384-def…" — and every conformant browser picks the strongest one it recognizes. That makes migrating between algorithms painless.
Generate the right hash
You never compute these by hand. Point a generator at the exact file (or URL) you are pinning and copy the emitted attribute. This tool produces all three algorithm variants so you can paste whichever your policy or CDN convention calls for:
What "secure" really means here
All three algorithms belong to the SHA-2 family, and none of them has a known practical collision or preimage attack. That is why the honest answer to "which is most secure?" is "they are equally unbroken today." The difference is future margin:
- SHA-256 — 256-bit digest. No practical attacks; perfectly adequate for SRI. Its only edge is the shortest
integritystring. - SHA-384 — 384-bit digest, computed as a truncated SHA-512. The community default: enough extra bits to feel comfortable for the long haul, standard across CDNs.
- SHA-512 — 512-bit digest. The largest safety margin and the longest attribute value; choose it when a security policy explicitly mandates the strongest available function.
Deliberately not allowed in SRI are MD5 and SHA-1 — both have practical collision attacks — and SHA-3, which the current specification simply does not include. If a generator or legacy snippet hands you an md5- or sha1- integrity value, treat it as broken and regenerate with SHA-384.
Practical recommendation
For nearly every website: use SHA-384, and match whatever your CDN already emits. Reach for SHA-512 only when a compliance policy demands the maximum digest length, and drop to SHA-256 only if you have a specific reason to minimize attribute size. Whatever you pick, generate the hash from the exact bytes you are serving, and remember that any change to the file — intentional or malicious — invalidates the hash and blocks the load. That last property is the whole reason SRI exists.