SHA-224 vs SHA-256: When Should You Use the Shorter Variant?

SHA-224 is the under-loved sibling of the SHA-2 family. It's been around since 2004, it's NIST-approved, it's cryptographically secure — and it's used so rarely that the Web Crypto API in browsers doesn't even support it. (Yes, we know — we implemented it ourselves to make this site work.) So when should you actually use it?

What SHA-224 actually is

SHA-224 was defined in NIST FIPS 180-2 (2004), alongside SHA-384 as a truncated variant of an existing algorithm. The mechanics:

1. Initialize with different initial hash values than SHA-256 (so the output differs even before truncation)
2. Run the exact same SHA-256 compression function
3. Output only the first 224 bits of the final state (the first 7 of 8 internal 32-bit words)

That's it. The algorithm is otherwise byte-identical to SHA-256.

Why different initial values?

If SHA-224 just truncated SHA-256, you could derive the SHA-224 of any input from its SHA-256 by chopping off the last 32 bits. That's not necessarily a problem for the hash function, but it does mean SHA-224 and SHA-256 would share collisions — finding two inputs that collide in SHA-256 would also produce SHA-224 collisions for free. The different initial values give SHA-224 mathematical independence from SHA-256 while sharing all the implementation work.

Security: not weaker than SHA-256 (with one caveat)

SHA-224's collision resistance is bounded by 2^112 (half the output size, per the birthday bound). SHA-256 is bounded by 2^128. Both are far beyond practical attack. The 16-bit difference is meaningless for real-world security — anything that could break SHA-224 by brute force could break SHA-256 in only 2^16 = 65,536× more time.

The caveat is length extension. SHA-256 is vulnerable to length-extension attacks: given SHA-256(secret || message) and the length of message, an attacker can compute SHA-256(secret || message || padding || attacker_chosen_data) without knowing the secret. SHA-224 truncates the internal state, which doesn't fully eliminate this attack but does reduce its impact. Practical defenses still apply: use HMAC instead of naked hash-then-secret patterns.

Performance: identical to SHA-256

Same block size (512 bits). Same number of rounds (64). Same compression function. The only difference is initial state and output truncation. Hashing 1 MB of data takes effectively the same time in either algorithm — the truncation is a single comparison instruction at the end.

The "advantage" of SHA-224 is 4 bytes saved per hash output: 28 bytes vs. 32 bytes. For a billion stored hashes that's 4 GB. For your auth system's session table, it's negligible.

Where SHA-224 actually appears

• PGP/OpenPGP — RFC 4880 explicitly lists SHA-224 as a supported hash algorithm. Used occasionally in signatures, though most modern PGP defaults to SHA-256 or SHA-512.
• DNSSEC NSEC3 — historical option, mostly superseded by SHA-256 today.
• Some TLS cipher suites — there are TLS_*_SHA224 variants, though almost no servers negotiate them.
• Government/regulatory contexts — some specifications mandate SHA-224 by name (rare).
• Smart cards and constrained hardware — where saving 4 bytes per hash actually matters and you have hardware-accelerated SHA-2 with no SHA-256 speed advantage.

Outside these specific cases, SHA-224 is rarely chosen. Most people who reach for a 32-bit hash do it for compatibility with a spec that names SHA-224 explicitly.

Web Crypto API: still doesn't support it

The Web Crypto API specifies SHA-1, SHA-256, SHA-384, and SHA-512. It deliberately omits SHA-224. The thinking from the working group: SHA-224 has so few real use cases that exposing it as a primitive would just confuse people.

For the rare browser-side need for SHA-224, you have two options: a pure-JavaScript implementation (like the one this site uses), or compute SHA-256 and truncate (which gives a different value — not equivalent to SHA-224).

The decision

Pick SHA-224 if:

• A spec, protocol, or standard says "SHA-224"
• You're working with PGP signatures that use SHA-224
• You're saving 4 bytes per hash at a scale where that matters (billions of records)

Otherwise, use SHA-256. It has wider library support, hardware acceleration on every modern CPU, and 4 extra bytes per hash that nobody notices.