SHA Hash Generator

What a hash is for

A cryptographic hash turns any input into a fixed-length fingerprint. The same input always produces the same digest, and even a one-character change produces a completely different one — which makes hashes ideal for verifying file integrity, comparing content, deduplication and digital signatures. Hashing is one-way: you cannot recover the original text from the hash.

Which algorithm should I use?

For anything security-sensitive, use SHA-256 or higher. SHA-1 and MD5 are cryptographically broken and must not be used to protect data. And remember: passwords need a salted, slow hash (bcrypt / scrypt / Argon2), never a plain SHA digest.

What makes a hash "cryptographic"

Plenty of functions scramble data, but a cryptographic hash function such as SHA-256 is engineered to satisfy a precise set of mathematical guarantees. Understanding them is the difference between using a hash correctly and trusting it for something it was never built to do.

• Deterministic. The same input always produces exactly the same digest — on any machine, in any programming language, today or in ten years. That is what lets two people compare a file by comparing 64 hex characters instead of the whole file.
• Fixed-size output. A three-letter word and a three-gigabyte movie both hash to the same length (256 bits for SHA-256). The input can be any size; the digest never grows.
• Fast to compute. Producing a digest is cheap and quick. This is a feature for integrity checks but a liability for password storage — which is exactly why passwords need a deliberately slow function, as noted above.
• Pre-image resistance (one-way). Given only a digest, it is computationally infeasible to find any input that produces it. You cannot "un-hash" a value back to its source — there is no decrypt button, because nothing was ever encrypted.
• Second-pre-image resistance. Given a specific file, it is infeasible to craft a different file with the same digest — so an attacker cannot quietly swap a download for a tampered version that still matches the published hash.
• Collision resistance. It is infeasible to find any two distinct inputs that share a digest. This is the property that broke for MD5 and SHA-1 (see below).
• The avalanche effect. Flip a single bit of the input and roughly half of the output bits flip too, with no visible pattern. "cat" and "cot" yield completely unrelated digests, so a hash leaks nothing about how similar two inputs were.

Note: the avalanche effect is a design goal that makes a hash look random; pre-image, second-pre-image and collision resistance are the three formal security properties cryptographers actually prove against.

Digest sizes at a glance

The number after "SHA" is the digest length in bits. Because each hexadecimal character encodes 4 bits, the hex string is always the bit length divided by four — a quick way to recognise which algorithm produced a hash just by counting characters.

A short history of SHA

The Secure Hash Algorithm family is published by the US National Institute of Standards and Technology (NIST), and the timeline explains why some members are trusted and others are retired:

• MD5 (1991). Designed by Ronald Rivest and published as RFC 1321 in 1992. A 128-bit digest that was the workhorse of the 1990s — and is now thoroughly broken.
• SHA-0 (1993). The original "SHA", released in FIPS 180, was withdrawn by the NSA almost immediately after a significant flaw was found.
• SHA-1 (1995). The patched replacement (FIPS 180-1), 160 bits. It became ubiquitous in TLS certificates, Git and software signing before falling to attack.
• SHA-2 (2001). The current standard family — SHA-224, SHA-256, SHA-384 and SHA-512 (FIPS 180-2). Still considered secure and the default choice today.
• SHA-3 / Keccak (2015). Won a public NIST competition in 2012 and was standardised as FIPS 202. Crucially it uses a completely different internal design (a "sponge") rather than the Merkle–Damgård structure of MD5/SHA-1/SHA-2, so an attack on one family does not carry over to the other.

How big are these numbers, really?

Security claims like "infeasible" rest on the sheer size of the search space. Thanks to the birthday paradox, finding any collision in an n-bit hash takes about 2^n/2 attempts — so collision resistance is effectively half the digest length. For SHA-256 that is roughly 2¹²⁸ operations: a number far larger than every computer ever built could work through in the lifetime of the universe. That margin is why a 256-bit digest is comfortable for the foreseeable future, while a 160-bit one (SHA-1) no longer is.

When hashes break: the collision attacks

"Broken" is not a figure of speech — it refers to specific, published attacks that found real collisions:

• MD5 — 2004. Xiaoyun Wang and colleagues demonstrated practical collisions, ending MD5's life as a security primitive.
• MD5 — abused in the wild, 2012. The Flame espionage malware used a chosen-prefix MD5 collision to forge a Microsoft code-signing certificate and disguise itself as a legitimate Windows Update — a textbook example of why a broken hash is dangerous, not academic.
• SHA-1 — "SHAttered", February 2017. Researchers at Google and CWI Amsterdam produced two different PDF files with the same SHA-1 hash, the first practical collision, at a cost of about 2⁶³ computations. An even more powerful chosen-prefix collision followed in 2020.
• SHA-1 — formally retired. In December 2022 NIST announced it will phase SHA-1 out of all uses by 31 December 2030, directing everyone to SHA-2 or SHA-3.

Both MD5 and SHA-1 still produce stable, useful fingerprints for catching accidental corruption — but because an attacker can manufacture collisions, neither can be trusted whenever an adversary might be involved.

Length extension, and why HMAC exists

MD5, SHA-1 and SHA-2 all build their digest with the Merkle–Damgård construction, processing the message block by block. A side effect is the length-extension attack: if you naïvely authenticate a message with hash(secret + message), someone who sees that digest can append extra data and compute a valid hash for the longer message without ever knowing the secret. This is why you should never roll your own keyed hash. Use HMAC (which nests the key and is immune), or SHA-3, whose sponge construction is not vulnerable in the first place. Among SHA-2 members, the truncated variants SHA-384 and SHA-512/256 also resist length extension, while SHA-256 and SHA-512 do not.

What hashes are actually used for

Beyond the obvious "verify a download", cryptographic hashing quietly underpins a huge amount of modern computing:

• File integrity & checksums — publishers post a SHA-256 next to a download so you can confirm the bytes you received are the bytes they shipped.
• Digital signatures — you sign the short hash of a document, not the whole thing, which is what makes signing large files fast.
• Message authentication (HMAC) — proving a message came from who you think and was not altered, using a shared key.
• Password storage — via a deliberately slow key-derivation function plus a salt (bcrypt / scrypt / Argon2), never a bare SHA.
• Deduplication — identical content hashes identically, so a backup or storage system can keep just one copy.
• Content addressing — Git names every commit and file by its hash (historically SHA-1, now migrating to SHA-256), and IPFS addresses content by its digest so the address is the integrity check.
• Proof-of-work — Bitcoin miners repeatedly hash a block header (with double SHA-256) searching for a digest below a target; the avalanche effect is what makes that search fair and unpredictable.
• Commitment schemes — publish hash(value) now to lock in a choice, and reveal the value later to prove you did not change your mind.

Salts, rainbow tables and peppers

A rainbow table is a giant precomputed lookup that reverses unsalted hashes almost instantly — so if a site stored plain SHA-256(password), a stolen database could be cracked in minutes. A salt defeats this: a unique random value mixed into each password before hashing means two users with the same password get different digests, and a precomputed table would have to be rebuilt for every salt — which is infeasible. The salt is stored alongside the hash and is not secret. A pepper goes one step further: a single secret value kept out of the database (in application config or a hardware module) and mixed in too, so an attacker who steals only the database still cannot test password guesses. This layered defence is what a real login system uses — and the reason a plain SHA digest is never enough for passwords.

Checksums are not cryptographic hashes

It is worth separating two ideas that look similar. A checksum such as CRC32 is built to catch accidental corruption — a flipped bit on a noisy network — and it does that cheaply. But CRC32 is linear and trivially reversible: an attacker can change a file and recompute a perfectly valid CRC, so it offers zero tamper resistance. When you need to detect deliberate modification, you need a cryptographic hash like SHA-256, not a checksum. This tool runs on your browser's built-in Web Crypto API (crypto.subtle.digest), which intentionally offers only SHA-1, SHA-256, SHA-384 and SHA-512 — and deliberately omits MD5 to discourage its use.

Hashing, encoding and encryption — three different things

These three words get mixed up constantly, and the confusion causes real bugs. They are not interchangeable:

• Hashing is one-way and deterministic. You can produce a digest from data, but you cannot get the data back from the digest. Its purpose is to verify, not to store or hide. A SHA-256 hash of "password" is the same for everyone and reveals nothing — but it also cannot be reversed.
• Encoding (such as Base64 or URL-encoding) is a reversible transformation for safe transport — anyone can decode it. It provides no secrecy whatsoever; it just repackages data into a different character set.
• Encryption is reversible with a key. It is designed to keep data secret from anyone without that key, and the same plaintext can be decrypted back exactly. This is the only one of the three meant to protect confidentiality.

So if someone says they "hashed the credit-card number so it's encrypted," they have made a category error: a hash is not encryption and cannot be decrypted. Use hashing to confirm something hasn't changed, encoding to move data safely through a text channel, and encryption when you actually need to keep it secret.

How to verify a download with its hash

The single most common everyday use of this tool is checking that a file you downloaded is genuine and intact. Many projects publish the SHA-256 of their installers and releases precisely so you can do this:

1. Find the official hash the publisher posted next to the download (often labelled "SHA-256" or "checksum").
2. Compute the SHA-256 of the file you actually received — on the command line with shasum -a 256 file (macOS / Linux) or certutil -hashfile file SHA256 (Windows), or by pasting text into the tool above.
3. Compare the two strings. If they match exactly, character for character, your copy is bit-for-bit identical to what the publisher released.

A single mismatched character means the file is different — it could have been corrupted in transit, or tampered with. Because of the avalanche effect, even a one-byte change produces a completely different digest, so this check is both simple and powerful. Just remember the limit: a checksum only proves the file matches the published hash — you still have to trust that the hash itself came from a legitimate source over a secure (HTTPS) page.

Frequently asked questions

Is a hash the same as encryption?

No. A cryptographic hash is one-way: it turns any input into a fixed-size fingerprint that cannot be reversed back into the original. Encryption is two-way (it can be decrypted with a key). Use hashing for integrity checks and fingerprints, not to "hide" recoverable data.

Can I use this to store passwords?

Not a plain SHA hash. Passwords must be stored with a slow, salted password-hashing function such as bcrypt, scrypt or Argon2 — never a bare SHA-256 or (worse) MD5. Fast hashes are designed to be fast, which is exactly what you do not want for passwords.

Why is there no MD5 here?

MD5 (and SHA-1) are cryptographically broken — practical collision attacks exist — so they should not be used for security. We focus on SHA-256 and above. SHA-1 is included only for legacy integrity comparison, clearly marked.

Does my input leave the browser?

No. Hashing uses your browser’s built-in Web Crypto API, so the text is processed locally and never uploaded. It also works offline once loaded.

Related tools

• UUID Generator
• Base64 Encoder / Decoder
• Text to Hex
• JSON Formatter & Validator
• URL Encode / Decode

See all developer & data conversions →