SHA-256 is a cryptographic hash function from the SHA-2 family, designed by NSA and standardized by NIST in 2001 (FIPS 180-4). It takes an input of any size and produces a 256-bit (32-byte / 64-hex-character) digest. The tool above computes the digest in your browser using the Web Crypto API; the input never leaves your machine.
What you can rely on
- Pre-image resistance. Given a digest, you cannot recover the input. No general inversion exists.
- Second-pre-image resistance. Given an input, you cannot find a different input with the same digest.
- Collision resistance. You cannot find any two different inputs that produce the same digest. The expected work to find one is ~2¹²⁸ operations — astronomically beyond current capability.
These properties make SHA-256 the right primitive for code-signing, certificate fingerprints, content-addressed storage (Git, IPFS), HMAC keying, and integrity checks for software distribution.
A worked example
Input: "hello"
Bytes: 68 65 6c 6c 6f
SHA-256: 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
Same input → same digest, every time, on every implementation. Change a single bit of the input — hellO instead of hello:
Input: "hellO"
SHA-256: 9b66e1681681bbd0d2f4cb6716c5404eaa6f793b09a3eee9d220fce6db7c40bd
Half the bits of the digest flip on average. This is the avalanche property — small input changes scramble the entire output. It’s why hashes work as integrity checks: any tampering, however minor, produces a completely different digest.
Where SHA-256 shows up
- TLS certificates. Modern X.509 certificates are signed using SHA-256 (or SHA-384). SHA-1 certificates were deprecated by browsers in 2017.
- JWT. The HS256 and RS256 algorithms use SHA-256 inside HMAC and RSA-PSS respectively. See the JWT decoder for what JWTs look like in practice.
- Bitcoin and most cryptocurrencies. Block hashes, transaction IDs, and proof-of-work puzzles all run on SHA-256.
- Software distribution. Linux package managers, container registries, and
*.sha256checksum files alongside downloadable binaries. Use the file hash verifier to compute a file’s SHA-256 directly. - Git (newer versions). Git is migrating from SHA-1 to SHA-256 for object IDs. SHA-1 remains the dominant default for now.
- Linux
apt/dnfpackage signing, macOS code signing, Authenticode for Windows binaries — all SHA-256-based.
SHA-256 vs SHA-512
Both are SHA-2 variants. Differences:
| Property | SHA-256 | SHA-512 |
|---|---|---|
| Digest size | 256 bits | 512 bits |
| Internal state | 32-bit words | 64-bit words |
| Speed on 64-bit CPUs | Baseline | Often faster (the wider words map to native register size) |
| Speed on 32-bit / embedded | Faster | Slower (64-bit ops are emulated) |
| Common use | Default | Higher-security applications, password-hashing variants |
If you’re not sure, SHA-256 is the right pick. SHA-512 is a reasonable choice on modern x86_64 / ARM64 servers where its slight speed advantage matters at scale. See the SHA-512 page for that variant.
SHA-256 is fast — that’s a problem for passwords
SHA-256 is designed to be fast — gigabytes per second on commodity hardware, billions of guesses per second on a modern GPU. That’s exactly the wrong property for password storage. If a server stores sha256(password) and the database leaks, an attacker dictionary-attacks every account in minutes.
Password storage requires a deliberately slow hash: bcrypt, scrypt, or Argon2. These functions tunably take ~100ms each, which is invisible to a legitimate login but reduces an attacker’s offline guessing rate by ~10⁹×.
A common pattern when a password-hashing library isn’t available: HMAC-SHA-256 with iterated re-hashing (PBKDF2). PBKDF2-SHA-256 with 600,000 iterations is the OWASP-recommended floor when you can’t use Argon2 or bcrypt. Plain SHA-256 once is wrong.
Common pitfalls
- Hashing without normalization. Hashing
"hello"and"hello\n"produces different digests. JSON with reordered keys hashes differently. If you want semantically-equivalent inputs to hash equally, canonicalize first. - Hashing as authentication. A hash alone proves the input wasn’t accidentally corrupted. Proving the input wasn’t intentionally substituted requires HMAC (a keyed hash) or a signature. See the hash generator for the broader picture.
- Confusing hex with base64 output. SHA-256’s 32 raw bytes can be displayed as 64 hex characters or 44 base64 characters. The bytes are the same; the encoding differs. The tool above emits hex.
- Comparing hashes with
==instead of constant-time. When verifying a digest in security-sensitive code, use a constant-time comparison to avoid timing attacks. Browser===reveals partial matches via timing. (For client-side checks of file integrity, this matters less.)
For other algorithms, see MD5, SHA-1, and SHA-512. For the multi-algorithm tool, see hash generator.