SHA-384 generator

SHA-384 generator is a free tool that converts string input into a fixed-length SHA-384 hash.

SHA-384's design and security record

SHA-384 turns data into a one-way, fixed-length 384-bit fingerprint. With SHA-384, the same input produces the same digest, while even a small input change usually produces a very different result. SHA-384 hashing does not encrypt data because there is no key that can later restore the original content.

SHA-384 belongs to the SHA-2 family designed by the U.S. National Security Agency and published by the National Institute of Standards and Technology in 2001. It uses the same general internal structure as SHA-512 but starts with different initial values and returns a 384-bit digest. That equals 48 bytes, normally displayed as 96 hexadecimal characters.

SHA-384 remains approved for modern cryptographic use. No practical collision attack is known against the full algorithm, and its expected collision resistance is about 192 bits. Its 64-bit operations can perform well on many 64-bit systems, although actual speed depends on the processor, software, and input size. It is generally slower than SHA-256 on systems optimized for 32-bit operations.

No, a SHA-384 hash cannot be decrypted or directly reversed. An attacker can still guess possible inputs, hash each guess with SHA-384, and compare the results. This is why hashing a short password, Social Security number, or other predictable value with plain SHA-384 does not hide it safely.

When should I choose SHA-384 instead of SHA-256 or SHA-512?

Choose SHA-384 when a specification requires it or when you need more collision resistance than SHA-256 with a shorter digest than SHA-512. All three algorithms are current members of the SHA-2 family, so the correct choice often comes from a protocol, API, certificate profile, or compatibility requirement rather than a general security ranking.

• SHA-256 produces 256 bits, or 64 hexadecimal characters. It is widely used and usually sufficient for checksums and content identifiers.
• SHA-384 produces 384 bits, or 96 hexadecimal characters. It commonly appears alongside cryptographic systems designed around roughly 192-bit security.
• SHA-512 produces 512 bits, or 128 hexadecimal characters. Choose it when a standard calls for the full SHA-512 digest or storage length is not a concern.

The SHA-256 generator and SHA-512 generator can help when another system expects those exact digest lengths. Hashes from different SHA-2 variants are not interchangeable, even when they are calculated from identical input.

What will the generator return for my input?

The generator returns one value in the SHA-384 Hash field. Enter the string to hash and submit it through the SHA-384 generator's page interface. The work runs on the server, so the input travels to the server over HTTPS and is not stored.

A SHA-384 result contains 96 hexadecimal characters using the digits 0 through 9 and letters a through f. For example, the input abc has this SHA-384 digest:

cb00753f45a35e8bb5a03d699ac65007272c32ab0eded1631a8b605a43ff5bed8086072ba1e7cc2358baeca134c825a7

Count the characters if a receiving system rejects the value because a SHA-384 digest requires 96 hexadecimal characters. A 64-character result is probably SHA-256, while a 128-character result is probably SHA-512. The SHA-384 output from this tool may appear in a different letter case in another system, but uppercase and lowercase hex represent the same bytes.

What happens with spaces, Unicode, or empty input?

SHA-384 hashes the exact bytes supplied, so spaces, punctuation, character encoding, and line endings can all change the result. The algorithm accepts data of any practical length and also defines a digest for empty data, but an interface may separately decide whether an empty field is valid input.

• Report, report, and report produce different hashes because capitalization and the trailing space are part of the input.
• To compare SHA-384 results for accented and non-Latin characters, every system must use the same character encoding. UTF-8 is common, but SHA-384 itself does not specify text encoding.
• Windows-style and Unix-style line endings use different bytes. Copying multiline content between applications can therefore change its SHA-384 result.
• In this SHA-384 generator, numbers entered into the string input are hashed as character data. The text 100 is different from a program's binary integer representation of 100.
• Very long input still produces exactly 96 hexadecimal characters. The fixed length of this SHA-384 generator's 384-bit output does not reveal input length.

Where does SHA-384 fit in current systems?

SHA-384 is suitable for integrity checks, deduplication identifiers, legacy compatibility, and protocols that explicitly select SHA-384. A stored SHA-384 digest can show whether data changed, provided the trusted digest itself has not been replaced.

Do not use plain SHA-384 to store passwords. Plain SHA-384 is designed to run quickly, which also lets attackers test password guesses quickly. Password databases should use a dedicated password-hashing scheme such as Argon2id, bcrypt, scrypt, or PBKDF2 with a unique salt and an appropriate work factor.

A plain SHA-384 checksum also does not prove who created a message. If an attacker can alter both the data and its published SHA-384 checksum, they can calculate a new matching SHA-384 checksum. Authenticated uses require a construction such as HMAC-SHA-384 or a digital signature.

Frequently asked questions

Does SHA-384 include a salt?

No. SHA-384 takes input bytes and returns a digest; salt handling belongs to the surrounding application or password-hashing scheme. Simply adding a salt to plain SHA-384 does not make it a suitable password-storage method because the calculation remains fast.

Can two different inputs have the same SHA-384 hash?

Yes in theory, because SHA-384's input domain of messages shorter than 2^128 bits is much larger than its finite set of 2^384 digests. Two different inputs that produce the same SHA-384 digest form a collision. Finding one for full SHA-384 is considered computationally impractical with known methods.

Should I store the hash with or without uppercase letters?

Both uppercase and lowercase representations of a SHA-384 digest are valid hexadecimal, but follow the format required by the receiving system. For database comparisons, normalize both values to one case or store the raw 48 digest bytes if the schema and application support binary data.

Can SHA-384 verify that a download is safe?

No. A matching SHA-384 hash confirms that the downloaded bytes match the bytes used to create the published SHA-384 digest. It does not show that the file is free of malware or that the source is trustworthy, so obtain the expected SHA-384 digest through a trusted channel and apply normal security checks.

Should an algorithm name be stored with the digest?

Usually, yes, when a database may contain SHA-384 digests and other hash types. Store metadata such as SHA-384 in a separate field or use the application's documented identifier format. The 96-character length is a useful clue, but length alone is not reliable algorithm metadata.