Programming tool

Hash Generator

Create SHA-256, SHA-384, and SHA-512 digests from UTF-8 text without uploading it.

Hexadecimal digest

Base64 digest

How the digest is produced

Whatever you type is first converted to bytes with TextEncoder, which encodes it as UTF-8 — so multi-line text, emoji, and non-Latin scripts like Japanese or Arabic all hash correctly, and an empty input is valid too. Those bytes are handed to the browser's native crypto.subtle.digest() function along with the algorithm you picked (SHA-256, SHA-384, or SHA-512), and the resulting digest bytes are rendered two ways: lowercase hexadecimal and standard Base64. The 'Load example' button fills the box with abc, the string used in the standard published test vectors for these algorithms.

Everything runs inside the Web Crypto API built into your browser's JavaScript engine. Your text is never packaged into a network request, so there's nothing to intercept between typing and seeing the digest.

What the algorithm choice actually changes

The three options differ only in output size, not in general trustworthiness — all three are current, unbroken members of the SHA-2 family. SHA-256 always outputs 256 bits (32 bytes), shown as 64 hex characters or 44 Base64 characters. SHA-384 outputs 384 bits (48 bytes): 96 hex characters or exactly 64 Base64 characters. SHA-512 outputs 512 bits (64 bytes): 128 hex characters or 88 Base64 characters. Hex always uses 2 characters per byte; Base64 packs 3 bytes into 4 characters, which is why it comes out shorter for the same digest.

The result is deterministic and one-way: the same input and algorithm always produce the same digest — SHA-256 of abc is always ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad on any standards-compliant system — but there is no operation that reconstructs abc starting from that hex string.

Hashing is not encryption

Encryption is built to be reversed: ciphertext plus the right key gets you back the original plaintext. Hashing throws information away on purpose and has no matching 'decrypt' step, so a digest is used to prove something wasn't altered, not to hide something you plan to recover later.

This generator deliberately doesn't offer MD5 or SHA-1. Both have known practical collision attacks — researchers publicly demonstrated a real SHA-1 collision in 2017 — which rules them out for anything security-sensitive, though they still work fine for detecting accidental file corruption where nobody is trying to fake a match. SHA-256 and its longer siblings here have no known practical collision attack, which is why Git (moving toward SHA-256), TLS certificates, and countless software update systems rely on them.

Where a text digest is actually useful

  • Confirming a downloaded file matches the SHA-256 checksum the publisher posted, before you run or install it
  • Fingerprinting a config file or document so you can tell at a glance whether two versions differ, without diffing the whole text
  • Producing a fixed-length cache key or database index for a large text blob instead of storing and comparing the full text
  • Checking that a webhook payload wasn't altered in transit by comparing it against a hash the sender also publishes
  • Comparing two large files for equality without reading either one back character by character
  • Demonstrating the avalanche effect for a class assignment by hashing near-identical strings side by side

Frequently asked questions

Is SHA-256 a form of encryption?

No. Encryption is reversible with the right key; hashing is one-way by design and produces no key to undo it. A hash lets you verify that data matches a known digest — it can't be used to recover the original text.

Can I use this to store user passwords?

No. A plain SHA-256, SHA-384, or SHA-512 digest of a password is fast to compute, which makes brute-forcing millions of guesses per second feasible. Password storage needs a slow, salted algorithm built for that purpose, such as Argon2, scrypt, bcrypt, or PBKDF2.

Why is the Base64 output shorter than the hex output?

They encode the exact same bytes with different alphabets. Hex spends 2 characters per byte, so a 32-byte SHA-256 digest is 64 hex characters. Base64 packs 3 bytes into 4 characters, so the same 32 bytes come out as 44 characters.

Does changing one character really change the whole hash?

Yes — that's the avalanche effect these algorithms are designed to have. Hashing abc and hashing abc with a trailing space produce digests with no visible relationship to each other, which is why a hash comparison only works when both sides are byte-for-byte identical.

Why doesn't this tool offer MD5 or SHA-1?

Both have documented, practical collision attacks — a real SHA-1 collision was published in 2017. This generator sticks to SHA-256, SHA-384, and SHA-512, none of which have a known practical collision attack today.

What does SHA-256 of an empty string look like?

It's a fixed, well-known value: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. An empty input is valid — you'll see this exact digest if you hash nothing at all with SHA-256 selected.