SHA-3/384 generator

SHA-3/384 generator is a free tool that converts string input into a 384-bit SHA-3 digest shown as 96 hexadecimal characters.

What does a SHA-3/384 result represent?

A SHA-3/384 result is a fixed-length fingerprint of the input data. SHA-3/384 accepts data of varying lengths and produces a fixed-length 384-bit digest. The SHA-3/384 digest is one-way, so it does not contain an encoded copy of the original input.

Even a small input change normally produces a completely different SHA-3/384 digest. That makes SHA-3/384 hashes useful for comparing data without comparing every byte directly. Matching SHA-3/384 hashes provide strong evidence that two inputs are the same, although hashing does not prove who created the data or protect it from deliberate replacement.

SHA-3/384 history and security status

SHA-3/384 is one member of the SHA-3 family standardized by the National Institute of Standards and Technology in FIPS 202 in 2015. The SHA-3/384 variant uses the SHA-3 construction based on Keccak, which was designed by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche and selected as the winner of NIST's SHA-3 competition in 2012.

The algorithm produces a 384-bit digest, equivalent to 48 bytes or 96 hexadecimal characters. Its expected collision resistance is about 192 bits. SHA-3/384 remains a current cryptographic hash and has no known practical break that makes the standardized algorithm unsafe for ordinary hashing applications.

SHA-3/384 is different from SHA-384. SHA-384 belongs to the older SHA-2 family and uses a different internal construction. It is also not byte-for-byte interchangeable with the original Keccak-384 function because standardized SHA-3 uses different domain-separation padding.

Where does SHA-3/384 fit today?

SHA-3/384 fits applications that require a 384-bit SHA-3 digest or compatibility with an existing format that names this algorithm. Its sponge construction also differs substantially from the Merkle-Damgård construction used by SHA-2.

• Checksums: Record a digest for a downloaded file or exported dataset, provided the file contents can be supplied to a suitable file-hashing implementation.
• Deduplication: Compare digests to find likely duplicate records or content before performing a byte-for-byte confirmation.
• Legacy and protocol compatibility: Reproduce values stored by software that already specifies SHA-3/384.
• Digital signature workflows: Use it when a signature standard or application profile explicitly calls for SHA-3/384.

Choose the algorithm required by the system receiving the digest. SHA-3/256 generator produces a shorter 256-bit result and is often sufficient for general checksums. SHA-3/512 generator may be appropriate when a protocol specifically requires a 512-bit SHA-3 digest. When choosing among SHA-3/256, SHA-3/384, and SHA-3/512, a longer digest is not automatically more compatible or more useful.

What happens to the text I enter?

The input travels to the server over HTTPS, where the server calculates the hash, and the input is not stored. The returned SHA-3/384 Hash field contains the resulting digest.

No, a SHA-3/384 digest cannot be decrypted or directly reversed because it is a hash, not encryption. However, someone can calculate SHA-3/384 digests for guessed inputs and look for a match, so short or predictable inputs are vulnerable.

Do not submit secrets merely because a hash is one-way. The text leaves your device during processing, even though the connection uses HTTPS and the service does not store the input.

How does exact input affect the digest?

SHA-3/384 hashes the exact bytes supplied to it, so spaces, punctuation, capitalization, and character encoding can affect the result. In this SHA-3/384 generator, two values that look similar on screen may have different byte representations and therefore different hashes.

• Invoice 1047 produces a 96-character hexadecimal digest.
• Invoice 1047 with a trailing space produces a different 96-character digest.
• 1047 entered in a text field is hashed as the text representation supplied by the application, not as an abstract number.
• To reproduce this generator's SHA-3/384 output for accented and non-Latin characters, another system must use the same character encoding and Unicode normalization as the input submitted here.
• SHA-3 defines a digest for empty input. However, this page's interface behavior for a blank field is not specified here.

The SHA-3 algorithm can process long inputs, but this tool does not state a maximum input size. For very large data or files, consider a local command-line utility or programming library to automate processing and avoid sending the content to a web server.

Should SHA-3/384 be used to store passwords?

No, SHA-3/384 should not be used by itself for password storage. Using SHA-3/384 alone lets an attacker test password guesses quickly.

Password databases should use a dedicated password-hashing function such as Argon2id, scrypt, bcrypt, or PBKDF2 with a unique salt and properly selected cost settings instead of SHA-3/384 alone. Adding a salt to plain SHA-3/384 does not turn it into a password-hashing function.

Questions people ask about SHA-3/384

Do SHA3-384 hashes use uppercase or lowercase letters?

The tool's 96-character SHA-3/384 result may use uppercase or lowercase hexadecimal letters without changing its numeric value. Comparisons should either use the same casing or decode both values as hexadecimal bytes. Keep all 96 characters, including leading zeros.

Why does my command-line checksum produce a different result?

The command may produce a different SHA-3/384 result because it hashes an extra newline, a file's raw bytes, or a different character encoding from this generator's string input. For example, shell commands that print text often add a line ending unless told not to. To reproduce the SHA-3/384 output from this string-input interface, compare the exact bytes supplied by each method rather than only the visible text.

Can I use a SHA-3/384 digest as a database key?

You can store the 48-byte digest or its 96-character hexadecimal form as a content identifier. A digest is larger than many ordinary database keys, and applications should still define how to handle the extremely unlikely event of a collision. If the identifier must be human-readable or sequential, a hash may be the wrong key type.

Does this generator decode hexadecimal input into bytes?

No hexadecimal-decoding option is documented. The tool accepts string input, so hexadecimal characters are hashed as text rather than converted to their represented byte values.

What should I record with a SHA-3/384 checksum?

Record the algorithm name, the digest, and enough information to identify the exact input. For text, also record the character encoding and any normalization rules. For files, note whether the checksum covers the original file, a decompressed version, or transformed content.