SHA-256 Hash Generator
Generate a SHA-256 hash from any text — or drop in a file to checksum it, and paste a known hash to verify.
About SHA-256
SHA-256 is part of the SHA-2 family and produces a 256-bit (64-hex-character) digest. It's the workhorse of modern cryptography — used in TLS certificates, blockchain, file integrity, and digital signatures. This tool uses your browser's native crypto.subtle over the UTF-8 bytes of your input, computed entirely on your device.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Verifying a release artefact against a checksum published through a different channel from the download.
- Producing a content-addressed identifier for a cache, a build artefact or a deduplicating store.
- Building the message digest step of an HMAC or a signature you are implementing.
- Confirming that two deployments shipped byte-identical bundles.
- Generating a stable fingerprint for a document in an audit trail.
How it works in practice
A worked example
A published checksum needs verifying, and you want to be certain the input reached the hasher at all.
hello world
b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9
Sixty-four hexadecimal characters, always, whatever went in — that is the two hundred and fifty-six bits of the name written four bits at a time. Change one character of the input and essentially every character of that string changes, which is what makes a digest useful for comparison: there is no such thing as a nearly matching hash, so two digests either agree or tell you nothing about how close the inputs were. The same bytes always produce the same digest, on any machine, in any language, forever.
The edge case that catches people
One digest is worth memorising the first few characters of: e3b0c442 begins the hash of the empty string. If a result starts that way, the input never arrived — an empty file, a variable that was undefined, a field that had not been filled in, a stream read twice. It is the single most common false result a hashing tool produces, and it looks exactly as authoritative as any other. A trailing newline is the same class of problem in reverse: hashing a file whose last line ends in one gives a different digest from hashing the visible text.
When not to use this tool
Not for passwords, and the reason is the opposite of a flaw. This is fast by design — hundreds of millions of digests a second on ordinary hardware — which is exactly what an attacker with a list of leaked passwords wants. Storing credentials needs a function that is deliberately slow and memory-hungry, so bcrypt or Argon2id rather than this. And a bare digest is not a signature: proving a message came from someone requires a key in the calculation, which means HMAC or a real signature scheme.
Frequently Asked Questions
- Why is SHA-256 the default recommendation?
- It has no known practical attack after two decades of analysis, it is required by TLS, Bitcoin, code signing and most compliance regimes, and it is hardware-accelerated on modern CPUs through the SHA extensions — fast and unbroken.
- What are its internal parameters?
- 256-bit digest (64 hex characters), 512-bit blocks, 32-bit words, 64 rounds. The 32-bit word size is what distinguishes it from SHA-512 and makes it faster on 32-bit hardware while SHA-512 wins on 64-bit.
- Is SHA-256 safe for passwords?
- No — for the opposite of the usual reason. It is too FAST: a GPU tries billions of SHA-256 guesses per second. Password storage needs a deliberately slow, memory-hard function: Argon2id, scrypt or bcrypt.
- What is a length-extension attack?
- Because SHA-256 is a Merkle-Damgård construction, knowing hash(secret || msg) and the length of secret lets an attacker compute hash(secret || msg || extra) without knowing the secret. This is why you must use HMAC rather than concatenating a secret yourself.
- How does it differ from SHA-3?
- Entirely different internals. SHA-256 is Merkle-Damgård; SHA-3 is a sponge over the Keccak permutation and is immune to length extension. SHA-3 was standardised as an insurance policy, not because SHA-2 fell.
- Why is SHA-256 so fast on modern hardware?
- Because most current x86 and ARM chips implement it in silicon — the SHA-NI extensions — making it several times faster than a software loop. That speed is a feature for checksums and precisely the problem for password hashing, where slowness is the defence.
- Why do some protocols hash twice?
- Bitcoin's `SHA256(SHA256(x))` and similar constructions defend against length extension, which the plain function is vulnerable to. Hashing the digest again means an attacker holding one has no valid internal state to continue from.
Common errors and gotchas
- Using it directly on passwords. Its speed is the point everywhere except there, and a GPU will try billions per second.
- Overlooking length extension. If you build a MAC as hash(secret + message) an attacker can extend it, which is why HMAC exists.
- Comparing digests with a non-constant-time comparison in code where timing is observable.
- Assuming the digest of a file matches the digest of its text content, when line endings and trailing newlines differ.
- Double hashing without a reason and then wondering why your value does not match the reference implementation.