What Is SHA-384 and Why Does It Exist Between SHA-256 and SHA-512?

SHA-384 exists because not every system wants the shortest digest or the biggest one. It gives you a SHA-384 hash with a 384-bit output, using the SHA-512 family’s internal machinery but trimming the final digest to a more practical size for some workflows. If you want to generate one right now, give our free SHA-384 hash calculator a spin.

What SHA-384 Actually Is

SHA-384 is part of the SHA-2 family, the same broad set of algorithms that includes SHA-224, SHA-256, SHA-384, SHA-512, and a few related variants. It is not a totally separate design; it is built from the SHA-512 compression function and then truncated to 384 bits of output.

That detail matters. A hash algorithm has two big jobs: process input in a deterministic way, and produce a fixed-size digest that is hard to reverse or collide with other inputs. SHA-384 keeps the SHA-512-style internals, which means it inherits the same general 64-bit word structure and large internal state, but it returns a shorter public digest than SHA-512.

In output terms, SHA-384 gives you 96 hexadecimal characters. SHA-256 gives you 64 hex characters. SHA-512 gives you 128 hex characters. So SHA-384 lands in the middle on visible size, even though its core engine is closer to SHA-512 than to SHA-256.

Why It Exists Between SHA-256 and SHA-512

The short answer is tradeoffs. Cryptographic tools often need to balance digest length, implementation constraints, protocol compatibility, and security margin. SHA-384 exists because sometimes you want a longer digest than SHA-256 without going all the way to the full 512-bit output.

In practice, SHA-384 can fit neatly into systems that expect stronger-than-SHA-256 branding or digest length, but do not want the extra storage or wire overhead of SHA-512. That is especially useful in certificates, signatures, logs, and database fields where every byte is accounted for.

There is also a standards angle. Some ecosystems picked SHA-384 as a supported option for TLS and certificate signatures, partly because it pairs well with certain key sizes and security policies. The algorithm did not appear because 384 is a magical number; it appeared because the gap between 256 and 512 was large enough to justify a middle option.

If you want a broader map of the family, our guide on which hash algorithm to use in practice is a good companion read. SHA-384 sits in the same decision space, even if the old MD5 ghosts are gone.

How SHA-384 Differs From SHA-256 and SHA-512

All three are fixed-length cryptographic hashes, but the output size changes what they cost and where they fit. SHA-256 outputs 256 bits, SHA-384 outputs 384 bits, and SHA-512 outputs 512 bits. That affects storage, display length, and sometimes protocol selection.

Here is the practical view:

• SHA-256 is the common default: shorter, widely supported, and usually enough.
• SHA-384 is the middle path: longer digest, SHA-512 core, good for compatibility with some security profiles.
• SHA-512 is the heavy version: longest digest, larger output, often used where maximum digest length is preferred.

Security-wise, longer digests make random collisions less likely in theory, but that does not mean you should reach for the biggest number by reflex. In many real systems, SHA-256 is already the standard choice because it is widely supported and more than adequate. SHA-384 is more about fit and policy than panic.

Implementation detail: SHA-384 uses the SHA-512 internal structure and different initial values, then truncates the output to 384 bits. That is why it is often described as a SHA-512-based variant rather than a standalone algorithm family member in the way SHA-1 used to be treated. The underlying compression rounds are still SHA-512-flavoured, which is part of why it exists at all.

When Developers Reach for SHA-384

Most developers do not pick SHA-384 because they are bored on a Thursday. They pick it when a system, standard, or security policy asks for it. The usual suspects are TLS certificates, signature schemes, compliance-driven setups, and some enterprise tooling where 384-bit digests are an accepted default.

It is also handy when you want a hash that is less cramped than SHA-256 in storage or display, but not as large as SHA-512. That can matter in:

• database columns holding digests
• audit logs and debug traces
• API payloads and signed tokens
• certificate fingerprints and signature metadata

One thing to keep straight: hashing and encryption are not the same thing. A SHA-384 hash is one-way by design; you do not decrypt it. You compare it, store it, or verify it against a fresh calculation. If you need reversible secrecy, you want encryption, not hashing.

For password storage, you usually should not use raw SHA-384 at all. Modern password systems need a slow, salted password hash such as bcrypt or scrypt, not a fast general-purpose cryptographic hash. If you are working in that area, the right question is about password hashing, not whether SHA-384 looks stylish in lowercase monospace.

What a SHA-384 Hash Looks Like

A SHA-384 hash is just a fixed-length hexadecimal string. It is not human-readable, it does not contain structure you can decode, and it will always be the same length for any input.

For example, a string like Hello, world might produce a digest that looks something like this:

0b3b3f4b0d4b7b0f5a5f7a0b0f2b7b5b4b6d5a2e5f4b1a6c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2

That sample is just a shape example, not a real computed result. The point is the format: 96 hexadecimal characters, no separators, no metadata, no mercy.

Because it is fixed length, SHA-384 is useful for indexing and comparison. If two inputs produce the same digest, you know the inputs were the same with overwhelming practical confidence, assuming the hash has not been broken for your use case. That is why hashes show up in file integrity checks, cache keys, and signature verification pipelines.

See It in Action

Here is a realistic workflow you might actually use. Say you have a config file and want to record a digest before shipping it to another environment. You hash the exact bytes, store the result, and later compare the stored value with a fresh calculation.

Input:

app_name=chunky-munster-demo
region=us-east-1
enabled=true

Conceptual result:

SHA-384 hash: 7a8f4c5d3e2b1a09d8c7e6f5a4b3c2d1e0f1029384756aabbccddeeff00112233445566778899aabbccddeeff0011

Now imagine a deployment script checking for drift. If the file changes even by one byte, the hash changes completely. That avalanche effect is why hashes are good at spotting tampering or accidental modification.

In code, the flow is usually tiny. In JavaScript, for example, you would hash the string and compare the digest:

const input = 'enabled=true';
// digest = sha384(input)
if (digest === expectedDigest) {
  console.log('match');
}

In a browser or tool workflow, you can use a calculator instead of wiring up crypto code by hand. That is often faster when you are debugging, checking documentation examples, or validating a digest copied from another system.

Frequently Asked Questions

Is SHA-384 stronger than SHA-256?

In terms of digest length, yes: SHA-384 returns a longer output, so brute-force collision search has more space to work against. In practical use, SHA-256 is already considered strong for most applications, so SHA-384 is usually chosen for compatibility or policy reasons rather than because SHA-256 is too weak.

Is SHA-384 just SHA-512 truncated?

Not exactly, though that is close to the right mental model. SHA-384 uses the SHA-512 core construction with different initial values and then outputs 384 bits. So it is SHA-512-based, not merely the same digest chopped off at the end.

Can I use SHA-384 for passwords?

Usually no. Raw SHA-384 is fast, which is exactly what you do not want for password storage. Use a purpose-built password hashing scheme such as bcrypt or scrypt, with salting and work-factor settings.

Why do certificates sometimes use SHA-384?

Some certificate and TLS setups prefer SHA-384 because it fits security profiles that want a larger digest than SHA-256. It is a common supported option in signature algorithms and can align with stronger key sizes and policy requirements.

The Bottom Line

SHA-384 exists because cryptography is mostly a game of sensible awkward compromises. It gives you a longer digest than SHA-256, a shorter output than SHA-512, and a SHA-512-based core that fits certain standards and deployments very well. If you are comparing hashes, storing digests, or checking signatures, that middle ground can be exactly the right kind of boring.

When you need to verify a value or inspect the output format, it helps to have a tool that stays out of the way. You can use the SHA-384 hash calculator here to generate test values, confirm lengths, or compare outputs while you work.

If you are deciding between SHA-256, SHA-384, and SHA-512, the real answer is still context. Check what your protocol, library, or policy expects, then pick the one that fits without adding unnecessary bulk.