🔒 SHA256 Hash Generator
Produce the 64 character SHA-256 hexadecimal digest of any text, computed in your browser with the Web Crypto API.
Auto-generate while typing
SHA-256 Hash Result
256-bit · 64 hex chars
Click anywhere on the hash to select it, or use the Copy button above.
About SHA-256
- • SHA-256 produces a fixed 256-bit (64 hex character) hash from any input.
- • Part of the SHA-2 family, standardised by NIST — considered cryptographically secure.
- • Even a tiny change in input produces a completely different hash (avalanche effect).
- • Common uses: password hashing, digital signatures, TLS certificates, blockchain, and file integrity verification.
-
🔒
Your text is hashed entirely in your browser using the native
crypto.subtleAPI — nothing is sent to any server.
Related Tools
🔒
🆔
🛡️
📱
MD5 Hash Generator
Turn any text into its 32-character MD5 hash in the browser, with optional auto-hashing as you type.
UUID Generator
Generate up to 100 version 4, 1 or 7 UUIDs in lowercase or uppercase and copy them in one click.
Password Strength Checker
Check a password against six rules and see a live strength rating with targeted suggestions.
QR Code Generator
Encode a URL or block of text as a QR code, choose its size and colours, and download the result as a PNG.
What SHA-256 does to your input
SHA-256 is a cryptographic hash function from the SHA-2 family, standardised by NIST. It takes an input of any length and produces a fixed 256 bit output, always the same size whether you hash one character or a whole book.
The tool first encodes your text as UTF-8 bytes, which matters because the hash is computed over bytes rather than characters. It then calls the browser's built-in digest function with the SHA-256 algorithm, which returns a 32 byte buffer. Each byte is finally rendered as two hexadecimal digits, giving the familiar 64 character string. Thirty-two bytes times two characters equals 64.
Three properties make the result useful. It is deterministic: the same input always produces the same digest anywhere in the world. It is one-way: there is no practical method of recovering the input from the digest. And it shows the avalanche effect: flipping a single bit of input changes roughly half the output bits, so similar inputs produce digests with no visible resemblance.
Because it uses the native Web Crypto API, the computation happens entirely inside the page and nothing is transmitted.
The tool first encodes your text as UTF-8 bytes, which matters because the hash is computed over bytes rather than characters. It then calls the browser's built-in digest function with the SHA-256 algorithm, which returns a 32 byte buffer. Each byte is finally rendered as two hexadecimal digits, giving the familiar 64 character string. Thirty-two bytes times two characters equals 64.
Three properties make the result useful. It is deterministic: the same input always produces the same digest anywhere in the world. It is one-way: there is no practical method of recovering the input from the digest. And it shows the avalanche effect: flipping a single bit of input changes roughly half the output bits, so similar inputs produce digests with no visible resemblance.
Because it uses the native Web Crypto API, the computation happens entirely inside the page and nothing is transmitted.
Worked example: hashing two similar strings
Hash the three characters abc and the result is the standard test vector ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. That is 64 hexadecimal characters, which is 32 bytes, which is 256 bits. This value is published as a reference vector, so it is a quick way to confirm any SHA-256 implementation is behaving correctly.
Now hash the eleven characters hello world. The result is b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9. Note that although the input is nearly four times longer, the digest is exactly the same length: the output size never varies with input size.
The avalanche effect is easy to demonstrate. Hashing hello world and Hello world, differing by one capital letter, produces two digests with no recognisable relationship to each other, not two strings that share a prefix. The same applies to a trailing space or an extra newline, which is the single most common reason a checksum comparison fails unexpectedly.
Hash abc a second time and you get the identical digest again, because the function has no randomness and no salt of its own.
Now hash the eleven characters hello world. The result is b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9. Note that although the input is nearly four times longer, the digest is exactly the same length: the output size never varies with input size.
The avalanche effect is easy to demonstrate. Hashing hello world and Hello world, differing by one capital letter, produces two digests with no recognisable relationship to each other, not two strings that share a prefix. The same applies to a trailing space or an extra newline, which is the single most common reason a checksum comparison fails unexpectedly.
Hash abc a second time and you get the identical digest again, because the function has no randomness and no salt of its own.
Where SHA-256 is the right tool and where it is not
To verify a download, hash the file's published value against the one you compute and compare the strings. They match exactly or they do not; there is no partial match, and a single differing character means the data differs. When comparing by eye, check the first and last several characters at minimum, or better, paste both into a comparison.
Beware of invisible differences. A trailing newline, a space at the end of a pasted line, or the same text saved with Windows rather than Unix line endings all change the bytes and therefore change the digest entirely. If two things that should match do not, that is usually why.
The important caveat concerns passwords. SHA-256 is fast by design, which is exactly wrong for password storage: an attacker with a stolen database can test billions of candidates per second. Passwords should be stored with a deliberately slow, salted algorithm such as bcrypt, scrypt or Argon2. SHA-256 is also not encryption, because nothing can be recovered from the digest, and it is not a secret: anyone who guesses your input can compute the same hash and confirm it.
Beware of invisible differences. A trailing newline, a space at the end of a pasted line, or the same text saved with Windows rather than Unix line endings all change the bytes and therefore change the digest entirely. If two things that should match do not, that is usually why.
The important caveat concerns passwords. SHA-256 is fast by design, which is exactly wrong for password storage: an attacker with a stolen database can test billions of candidates per second. Passwords should be stored with a deliberately slow, salted algorithm such as bcrypt, scrypt or Argon2. SHA-256 is also not encryption, because nothing can be recovered from the digest, and it is not a secret: anyone who guesses your input can compute the same hash and confirm it.
Frequently Asked Questions
No. The hash is computed by your browser's native Web Crypto API inside the page, so the text you type stays on your device. That also means the tool keeps working once the page has loaded, and there is no request carrying your input anywhere for a third party to observe or log.
SHA-256 always produces 256 bits, which is 32 bytes. Written in hexadecimal each byte takes two characters, so 32 bytes becomes 64 characters. The length never changes with the input, so a single letter and a long document both produce exactly 64 hexadecimal characters.
Not by computation. The function discards information and cannot be run backwards. What can be done is guessing: an attacker who suspects the input can hash candidates and compare. That works well against short or predictable inputs such as common passwords, which is why hashing alone is not a way to keep a short secret.
No. SHA-256 is deliberately fast, which lets an attacker test enormous numbers of guesses against a leaked database. Password storage needs a slow, salted algorithm designed for the purpose, such as bcrypt, scrypt or Argon2. Use SHA-256 for integrity checking, fingerprinting and checksums instead.
Usually because the bytes differ in a way you cannot see. A trailing newline, a stray space, different line endings between Windows and Unix, or a different text encoding will each produce a completely different digest. It can also mean you hashed pasted text rather than the file itself, which hashes differently.