Hash Generator: SHA-256, SHA-384, SHA-512

Choose the right hash for files, checksums, HMACs, and passwords. This browser-first guide explains SHA-2, output formats, and the traps to avoid.

A digest is a compact fingerprint of bytes, not an encrypted copy. The hash generator on Control Plane Labs computes common digests locally in your browser, including file hashes and HMACs. That makes it useful for checking a download, comparing two artifacts, or reproducing the value a webhook or build system expects.

What does a cryptographic hash do?

A cryptographic hash maps an input of arbitrary length to a fixed-size output. NIST’s Secure Hash Standard describes SHA-1 and SHA-2 algorithms as functions that produce message digests; SHA-256 produces a 256-bit result, normally displayed as 64 hexadecimal characters. A one-byte change should produce a different digest, which is why a published checksum can reveal an altered or incomplete download.

Hashing is not encryption. Encryption is designed to be reversed with a key; a digest is intended to be one-way. It is also not authentication by itself. If an attacker can replace both a file and its checksum, a matching hash proves only that the two came from the same replacement. For release verification, obtain the checksum from a channel you trust, then compare it with a locally computed value.

Which hash should you choose?

For a new file checksum or content fingerprint, choose SHA-256 unless the protocol specifies another algorithm. It is widely implemented, produces a manageable 64-character hexadecimal value, and is supported by the browser Web Crypto API and server runtimes.

SHA-384 and SHA-512 are members of the SHA-2 family with 384-bit and 512-bit outputs. Use them when a vendor publishes that checksum, a signature profile requires them, or a policy calls for a longer digest. A longer output is not automatically better: compatibility matters more than the largest number.

SHA-1 and MD5 belong in legacy compatibility checks only. The SubtleCrypto.digest() documentation marks SHA-1 as vulnerable for cryptographic applications. A checksum from an old system may still need to be reproduced, but do not select either algorithm for a new signature, certificate, release-integrity workflow, or security decision.

Browser hashing, files, and encoding

The browser’s SubtleCrypto.digest() accepts bytes and returns a Promise for an ArrayBuffer. It supports SHA-1, SHA-256, SHA-384, and SHA-512, but it does not provide a streaming digest: the complete input must be in memory. For a small text value, UTF-8 encoding is the important detail. The string café is not the same byte sequence under every legacy encoding, so two tools can disagree if one side hashes text after a different conversion.

async function sha256Hex(text) {
  const bytes = new TextEncoder().encode(text);
  const digest = await crypto.subtle.digest("SHA-256", bytes);
  return [...new Uint8Array(digest)]
    .map((byte) => byte.toString(16).padStart(2, "0"))
    .join("");
}

For a local file, read the file as an ArrayBuffer, hash those bytes, and show the result as hexadecimal or base64. Hex is easy to compare in a terminal; base64 is shorter and is the representation used by several web security formats. The Subresource Integrity guidance shows why the algorithm name must travel with a base64 digest: sha384-... is a complete SRI token, not just an arbitrary encoded string.

If a shell result differs from the browser, compare bytes before blaming the algorithm. echo "hello" usually adds a newline, while a text box containing hello does not. A different line ending, encoding, or trailing space changes the digest. With binary files, make sure both tools read the same file.

The Node.js crypto documentation uses createHash() with update() and digest() for server-side hashing. Node can stream data into a hash, which is the better choice for a multi-gigabyte artifact that should not be loaded into one browser buffer. For a small value, the one-shot form is simpler; name the encoding when you turn the result into a string.

Why a hash generator is not a password tool

A password database needs a deliberately slow, salted password-hashing function, not a fast general-purpose digest. OWASP’s Password Storage Cheat Sheet recommends Argon2id, scrypt, bcrypt, or PBKDF2 with a unique salt per password. SHA-256 is excellent for a file checksum precisely because it is fast; that same speed lets an attacker test huge numbers of password guesses.

Do not paste a real password, API token, private key, customer export, or other secret into an online tool unless you have verified its data-handling model. The hash tool here is designed to run in the browser, but client-side execution does not turn a password into a safe credential workflow. For a password-related task, use the password tool for strength feedback and implement storage with a server-side adaptive password function.

A related distinction applies to signatures. RFC 8017 describes how RSA schemes combine a message digest with a signature encoding. A hash value alone is not a signature and does not prove who produced it. If your protocol says HMAC, signature, or password hashing, follow that protocol instead of substituting a plain digest because the output looks similar.

A three-minute verification routine

1. Identify the promised bytes. Is the value for a file, a UTF-8 string, a request body, or a serialized object? Write down encoding, line endings, and whether a newline is included.
2. Match the algorithm and format. Select the exact SHA family member and compare hex with hex or base64 with base64. Do not compare a hex string to a base64 string without decoding one side.
3. Check the trust boundary. A checksum from the same untrusted download location is not an independent authenticity signal. Use HMAC for a secret-key workflow or verify a signature through a trusted key path.

Read next

• Try the hash generator for text or local files.
• Use the TLS certificate inspector for certificate fingerprints and expiry details.
• Read the JWT decoding guide when a token’s signature algorithm is the question.

Tags: #hashing, #sha-256, #web-crypto, #security