crypto.subtle.digest throws if you ask for SHA-224
Open the console on this page and run:
await crypto.subtle.digest('SHA-224', new Uint8Array())Chrome, Firefox, and Safari reject the call. The Web Cryptography API names SHA-1, SHA-256, SHA-384, and SHA-512. SHA-224 never made the list.
Node accepts crypto.createHash('sha224'). OpenSSL accepts openssl dgst -sha224. Java MessageDigest.getInstance("SHA-224") works. The browser is the odd one out, and that gap is where the bad shortcut is born.
A frontend already hashing SHA-256 through Web Crypto keeps the first 56 hex characters and labels the result SHA-224. The label is a lie. The number is a different hash. The trap row on the bench prints both strings for one input so the mismatch is visible, not a footnote in FIPS 180-4.
This page runs SHA-224 in the tab, in JavaScript, because the platform API refuses. Files are read with FileReader. Nothing is uploaded. Load the page once, cut the connection, keep hashing.
Seven words leave the function. Eight words ran inside it.
SHA-224 is not a smaller cousin with a smaller engine. It is the SHA-256 compression function wearing a different start state.
512-bit blocks. 64 rounds. Eight 32-bit registers. FIPS 180-4 seeds those registers from the 32 high bits of the fractional parts of the square roots of primes 23 through 53, which is a long way of saying the IV is not the SHA-256 IV. After the last round the engine still holds 256 bits. The published digest is the first 224. The eighth word is computed, then thrown away.
| Register | SHA-224 IV | SHA-256 IV |
|---|---|---|
| h0 | c1059ed8 | 6a09e667 |
| h1 | 367cd507 | bb67ae85 |
| h2 | 3070dd17 | 3c6ef372 |
| h3 | f70e5939 | a54ff53a |
| h4 | ffc00b31 | 510e527f |
| h5 | 68581511 | 9b05688c |
| h6 | 64f98fa7 | 1f83d9ab |
| h7 | befa4fa4 | 5be0cd19 |
The register strip on the bench follows those eight names. h0 through h6 concatenate into the 56 hex characters you copy. h7 sits in the copper cell labelled dropped. Copy never includes it. Treating the dropped word as optional output is how two implementations drift.
Press abc on the vector row. The seven published words read 23097d22, 3405d822, 8642a477, bda255b3, 2aadbce4, bda0b3f7, e36c9da7. FIPS 180-4 prints that exact string. A mismatch on the first official test case means the implementation is broken. Stop there.
Cutting SHA-256 to 56 characters is a different hash
People expect a prefix. They never get one.
Because the start state differed, every round differed, so the surviving 224 bits share no leading bytes with SHA-256 of the same input. Look at the first byte of the empty-string pair. Already different.
| Input | SHA-224 | SHA-256 sliced to 56 hex |
|---|---|---|
| empty string | d14a028c2a3a2bc9…e42f | e3b0c44298fc1c14…991b |
abc | 23097d223405d822…9da7 | ba7816bf8f01cfea…ff61 |
toolexe.com | 744cd11038d00918…cbf9 | a different 56 characters again |
I have watched a payment callback fail for a week because one vendor called SHA-224 and the other truncated SHA-256, both ticking a box labelled SHA-2. The shared 56-character width hid the bug. Width is not identity. The SHA-2 family board is the place to see all four members at once. This page exists for the one mix-up those 56 characters keep causing.
Holding 56 hex characters from a vendor right now. Paste them into the check field on the bench. A match against the truncated SHA-256 row means the publisher hashed the wrong function. Re-downloading the file will not fix a wrong algorithm.
Collision work sits near 2112. Skip this width on new work.
A birthday attack against a 224-bit digest costs about 2112 operations. NIST's current floor for collision resistance on new federal systems is 128 bits. SHA-224 misses it.
TLS 1.3 does not name SHA-224. Public certificate chains moved off it years ago. CNSA 1.0 pairs AES-256 with SHA-384, not with this member. Browser Web Crypto omitted it on purpose.
For new work the defaults are boring on purpose. SHA-256 unless a profile names another member. SHA-384 if a government checklist is on the desk. SHA-512/256 if you want 256 bits from the 64-bit engine without publishing the full internal state. All three beat 224 bits on the only metric that matters for a new hash: collision work.
Two other hashes also print 56 hex characters
A 56-character string is not a fingerprint of SHA-224.
SHA-512/224 runs the 64-bit SHA-512 engine with its own IV, then keeps 224 bits. Same width. Different number. Faster on 64-bit hardware, which is why some teams reach for it and then paste the result into a SHA-224 field.
SHA3-224 belongs to Keccak. Sponge construction, different padding, different everything. Same width again.
Count the characters, then name the family from context. A CMS blob from 2012 is usually SHA-224. A SHA-3 migration is usually SHA3-224. Guessing from width alone is how two 56-character strings sit in a ticket for three days while both sides insist the file is fine.
Throwing a word away closes length extension. HMAC still belongs on keyed data.
SHA-256 publishes its entire internal state as the digest. Anyone holding hash(secret || message) resumes the compression function and forges a valid digest for a longer message, without the secret. SHA-224 throws 32 bits of state away, so the published digest is not enough to resume. SHA-384 does the same trick on the 64-bit engine.
A narrow win. Not a substitute for a keyed construction.
Request signatures, webhook tags, and API auth still want HMAC. The HMAC generator on this site takes SHA-256 or SHA-512. SHA-224 as an HMAC inner hash shows up in old CMS signed attributes. A new integration has no reason to start there.
Password storage is a different refusal. SHA-224 is fast. Fast helps a GPU working through a leaked table. Argon2id, scrypt, or bcrypt belong there. Hashing a password on this bench will not reproduce a shadow entry, a WordPress $P$ hash, or any stretched construction.
What this page will not do
- Reverse a digest. Sites offering to decrypt SHA-224 are searching lists of common strings.
- Emit SHA-512/224 or SHA3-224. Those are different functions with their own generators.
- Hash files past about 48 MB. The browser holds the bytes in memory, then runs a JavaScript compression loop. Disk images belong with
openssl dgst -sha224orsha224sum. - Salt, iterate, or HMAC.
- Treat a matching digest as proof the publisher is legitimate. A match proves the bytes equal a published value. Check the checksum file's signature, or use the Checksum Validator when a whole manifest is involved.
Line endings are hashed as they arrive. CRLF versus LF rewrites every word on the strip. echo appends a newline. printf does not. The byte counter above the bench is the first place to look when a terminal disagrees with this page.
printf %s abc | openssl dgst -sha224
# 23097d223405d8228642a477bda255b32aadbce4bda0b3f7e36c9da7
echo abc | openssl dgst -sha224
# a different digest, because echo added a newline
openssl dgst -sha224 release.tar.gz
sha224sum release.tar.gzEmpty-string SHA-224 is d14a028c2a3a2bc9476102bb288234c415a2b01f828ea62ac5b3e42f. If the hex row disagrees on an empty box, stop and check the browser.
