Passwords & Hashing
What Does SHA Stand For?
SHA stands for Secure Hash Algorithm. Learn what a hash does, how SHA-1, SHA-2, and SHA-3 differ, and when to use SHA-256, SHA-512, or SHAKE.
SHA stands for Secure Hash Algorithm. It names a family of mathematical procedures that turn data into a short digital fingerprint called a hash or digest. You can hash a word, a document, or an entire software download to get a value you can compare later.
SHA-1 is a legacy algorithm, SHA-2 is a widely used family that includes SHA-256 and SHA-512, and SHA-3 is a separate family built differently. For new checksum workflows, start with SHA-256. When an application or protocol specifies an algorithm, use that exact one.
What the S, H, and A mean
- S means Secure. These algorithms are designed to make certain attacks impractical, including finding an input that produces a chosen digest or finding two different inputs with the same digest. An algorithm can lose those protections as attacks improve; SHA-1 is the important example.
- H means Hash. Hashing maps input data to a digest. For a fixed-output algorithm such as SHA-256, the digest has the same length whether the input is three letters or a large file.
- A means Algorithm. An algorithm is a precise set of steps. Anyone applying the same SHA variant to exactly the same bytes gets exactly the same result.
NIST defines the abbreviation and the SHA-1/SHA-2 algorithms in the Secure Hash Standard, FIPS 180-4.
What a SHA hash tells you
A hash gives you a compact way to compare content. Compute a file's SHA-256 digest before sending it, compute it again after receiving it, and compare the results. Different digests mean the bytes differ. A matching SHA-256 digest gives very strong evidence that the bytes match.
A small input change normally produces a very different digest. It does not tell you where a change happened; for that, you need to compare the actual content.
Hashing also does not provide a decryption operation. Encryption lets someone with the right key recover the original message. A hash supports comparison. Someone can still guess an input, hash the guess, and check whether it matches, which matters especially for passwords. The guide to encryption, encoding, and hashing explains those different jobs.
For a download, get the expected checksum from a source you trust. If someone can replace both the file and its advertised checksum, matching them will not establish who published the file. See how to verify a downloaded artifact with checksums and signatures for that workflow.
The SHA families at a glance
The names mix family numbers and output sizes. SHA-256 belongs to SHA-2. SHA-3-256 belongs to SHA-3. Both produce 256-bit digests, but they use different algorithms and produce different values for the same input.
| Name | What it refers to | Output size | Where it fits |
|---|---|---|---|
| SHA-1 | One older algorithm | 160 bits | Existing formats and legacy compatibility; avoid it for new security designs |
| SHA-2 | A family of six algorithms | 224, 256, 384, or 512 bits | Widely used checksums and cryptographic protocols |
| SHA-3 | A different family of four fixed-output algorithms | 224, 256, 384, or 512 bits | Systems that specify SHA-3 or choose its different internal design |
| SHAKE128 and SHAKE256 | Extendable-output functions in the SHA-3 standard | Chosen by the caller | Protocols that need a specified amount of hash output |
These families are documented in FIPS 180-4 and the SHA-3 standard, FIPS 202. The original 1993 SHA, now usually called SHA-0, preceded SHA-1 and is obsolete.
SHA-1: the legacy algorithm
SHA-1 produces a 160-bit digest, usually written as 40 hexadecimal characters. You may encounter it in older checksums, identifiers, and software formats.
Its major weakness is collision resistance: attackers have demonstrated ways to construct different inputs with the same SHA-1 digest. That undermines uses that depend on a hash distinguishing deliberately crafted documents. It does not mean every SHA-1 digest can simply be reversed to recover its input.
NIST plans to transition away from SHA-1 for applying cryptographic protection by December 31, 2030, and encourages moving sooner. See NIST's SHA-1 transition guidance.
If you need to reproduce an existing SHA-1 text value, the SHA-1 Generator can help. For a new checksum workflow, start with SHA-256.
SHA-2: the family behind SHA-256 and SHA-512
SHA-2 includes six named algorithms. The number at the end gives the digest length in bits. Because one hexadecimal character represents four bits, divide the bit count by four to get the length of a hex digest.
| SHA-2 algorithm | Digest bits | Digest bytes | Hex characters |
|---|---|---|---|
| SHA-224 | 224 | 28 | 56 |
| SHA-256 | 256 | 32 | 64 |
| SHA-384 | 384 | 48 | 96 |
| SHA-512 | 512 | 64 | 128 |
| SHA-512/224 | 224 | 28 | 56 |
| SHA-512/256 | 256 | 32 | 64 |
SHA-256 and SHA-512 use different working sizes
SHA-256 processes data in 512-bit blocks using 32-bit words internally. SHA-512 uses 1,024-bit blocks and 64-bit words. Those are working sizes inside the algorithm; the final digests remain 256 and 512 bits respectively.
SHA-224 follows the SHA-256 construction with different starting values and a shorter output. SHA-384 similarly follows the SHA-512 construction with different starting values and a shorter output.
For text, use the SHA-256 Generator or SHA-512 Generator. For the bytes of an actual file, use File Checksum.
SHA-512/256 is different from SHA-256
SHA-512/256 uses the SHA-512 construction but produces a 256-bit digest. It has its own starting values, so it is also different from taking the first half of a normal SHA-512 digest. SHA-512/224 follows the same idea with a 224-bit result.
This is why length alone cannot identify a hash. SHA-256, SHA-512/256, and SHA-3-256 can all appear as 64 hex characters. A tool such as Hash Identifier can narrow possibilities, but the application or specification that created the value determines which algorithm to use. The variant definitions come from FIPS 180-4.
SHA-3: a different design
SHA-3 provides SHA3-224, SHA3-256, SHA3-384, and SHA3-512. You will also see them written as SHA-3-224, SHA-3-256, and so on. Their suffixes describe the digest length, just as in SHA-2.
Internally, SHA-3 uses a design called a sponge, based on Keccak. It absorbs input into an internal state, repeatedly mixes that state, then squeezes out the result. SHA-2 instead uses a different block-processing construction.
SHA-3 supplements SHA-2; existing SHA-2 applications do not need to migrate just because SHA-3 is available. If a protocol expects SHA-256, substituting SHA3-256 will fail because the digest changes. See NIST's policy on hash functions.
Keccak-256 and SHA3-256 produce different digests. Although SHA3-256 is based on Keccak, it adds different marker bits to the input before processing it. A library option named Keccak-256 is not an interchangeable spelling of SHA3-256.
SHAKE lets the caller choose the output length
The SHA-3 standard also defines SHAKE128 and SHAKE256, called extendable-output functions, or XOFs. You specify how much output you want instead of always receiving a fixed digest length.
Here, 128 and 256 describe security-strength targets, not fixed output lengths. For example, requesting 256 output bits from SHAKE128 gives 32 bytes. It does not turn it into SHAKE256 or SHA3-256, and requesting more bytes does not increase security without limit. Collision strength is also limited by the amount of output requested. Use the function and output length your protocol specifies. FIPS 202 defines these functions and their distinctions.
Try SHA-256 with three letters
Enter abc in the SHA-256 Generator, with no spaces or line break. The UTF-8 input is three bytes; the digest is 32 bytes, displayed as 64 hex characters.
You can reproduce it with OpenSSL:
printf '%s' 'abc' | openssl dgst -sha256
The digest is:
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
Hex is a way to display the digest, rather than part of SHA itself. The same digest bytes can also be displayed in Base64. For JSON and other structured text, agree on serialization before hashing; canonical JSON for signing and hashing explains why formatting alone may not be enough.
Choose the algorithm for the job
| Your task | Appropriate next step |
|---|---|
| Create a new file checksum | Use SHA-256 in File Checksum, then document the expected value and algorithm |
| Match a digest another system supplied | Use that system's exact algorithm, original bytes, and output encoding |
| Authenticate a message with a shared secret | Use a standard keyed construction such as HMAC-SHA-256 |
| Store login passwords | Use a password-hashing function such as Argon2id with suitable parameters and a unique salt |
| Implement a protocol that calls for SHA-3 or SHAKE | Follow its algorithm name and, for SHAKE, output length exactly |
A plain SHA digest has no secret key, so anyone who changes a message can compute a new digest. HMAC combines a hash with a shared secret to authenticate messages. The guide to HMAC and digital signatures explains how the verification model changes.
Password storage needs a different property: making each guess expensive. SHA-256 and SHA-512 are designed to be fast, which helps someone testing password guesses. Adding a salt to a single SHA operation does not fix that speed problem. OWASP recommends Argon2id for new password storage; the SHA-256, MD5, and bcrypt comparison covers how password hashing differs from checksums.
Does a larger number always mean more security?
For an ideal fixed-output hash with an n-bit digest, a generic search for any two colliding inputs takes roughly 2^(n/2) work. Finding an input for one specified digest, called a preimage attack, takes roughly 2^n work. Thus SHA-256 targets about 128 bits of collision resistance and 256 bits of preimage resistance against generic classical attacks. NIST summarizes these strengths in its hash-function security guidance.
A longer digest can raise those limits, but it cannot fix an untrusted checksum source, a guessed password, or hashing the wrong bytes. Follow a SHA-256 checksum workflow to generate a file digest and compare it with the expected value.
