SHA-256 Hash Generator & Verifier
Generate SHA-256 hashes from text or files and verify them against an expected checksum. Streams large files in your browser, supports UTF-8/UTF-16/Latin-1/Windows-1252 and hex/base64 input, HMAC-SHA256, and hex or base64 output.
Runs entirely in your browser. Text is hashed with the native Web Crypto API and files are streamed through WebAssembly — nothing is uploaded, nothing is logged. Verify it yourself: open DevTools → Network, hash a 2 GB file, and watch zero requests appear.
SHA-256 digest
0 bytes hashed — canonical empty-input digestFix the input above to see a digest.
Input
0 characters · 0 encoded bytes
UTF-8 is what sha256sum, Git, and every modern web API use. Leave it selected unless you are reproducing a legacy system's hash.
Compare against an expected hash
Paste the publisher's checksum — bare hex, base64, a sha256sum line (hash filename) or a BSD SHA256 (file) = hash tag all work.
The verdict appears as soon as both a digest and an expected hash exist. Works for text and files — the browser equivalent of sha256sum -c.
Other algorithms
Compute MD5, SHA-1, SHA-256 and SHA-512 of the same input to identify an unknown digest. Loads a small WebAssembly module (for MD5) on demand — that is why it is opt-in.
Do not use SHA-256 to store passwords
SHA-256 is built to be fast — a single modern GPU computes billions of SHA-256 hashes per second, so a stolen table of SHA-256 password hashes falls to brute force almost immediately, salt or no salt. Password storage needs a deliberately slow, memory-hard function: Argon2id, bcrypt (cost ≥ 12), scrypt or PBKDF2 with 600,000+ iterations. Use SHA-256 for fingerprints, signatures and integrity — never as the thing between an attacker and a user's password.
Why two tools disagree about "the" SHA-256 of your text
- • A trailing newline.
echo "abc" | sha256sumhashes 4 bytes, not 3. Useecho -nor this tool's trailing-newline toggle. - • A BOM. UTF-16 (and sometimes UTF-8) files from Windows editors start with 2–3 extra bytes that most online tools silently add and CLIs never do.
- • The encoding itself. "café" is 5 bytes in UTF-8, 4 in Latin-1, 8 in UTF-16 — three different digests for the same visible text.
- • Byte order. UTF-16LE and UTF-16BE hold the same characters in opposite byte order and therefore hash differently.
- • CRLF vs LF. A file checked out on Windows may differ from the same file on Linux by one byte per line.
Technical specifications
- • Algorithm: SHA-256, the 256-bit member of the SHA-2 family (NIST FIPS 180-4)
- • Output: 256 bits = 32 bytes = 64 hex characters = 44 base64 characters
- • Block size: 512-bit blocks, Merkle–Damgård construction with length padding
- • Empty input: SHA-256 of zero bytes is
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 - • Text engine: native
crypto.subtle.digest(Web Crypto API) - • File engine: hash-wasm streaming SHA-256, 4 MiB chunks, constant memory use
- • Verification: hex compared case-insensitively, base64 compared case-sensitively (base64 is a case-significant alphabet)
Common use cases
About SHA-256 Hash Generator & Verifier
The SHA-256 Hash Generator & Verifier computes SHA-256 digests of text or files and checks them against a hash you already have. Text is hashed live as you type with the browser's native Web Crypto API; files are streamed through WebAssembly in 4 MiB chunks, so a multi-gigabyte ISO is hashed without ever being loaded into memory. Input can be interpreted as UTF-8, UTF-16LE, UTF-16BE, ISO-8859-1, Windows-1252, raw hex or base64 bytes, and the digest can be read as lower-case hex, upper-case hex or base64.
Why use a SHA-256 Hash Generator & Verifier?
Most online SHA-256 tools quietly make one of three mistakes: they prepend a byte-order mark to UTF-16 input, they refuse empty input (so you can never see the canonical empty-string digest), or they lowercase both sides when verifying — which breaks base64 comparison, because base64 is case-significant. This tool does none of those. It hashes exactly the bytes you asked for, allows empty input, streams real files instead of pretending text is enough, and tells you which format it compared and why the verdict came out the way it did.
Who is it for?
Developers reproducing a checksum from a build pipeline, release engineers verifying a download against a publisher's sha256sum line, API integrators debugging HMAC-SHA256 request signatures, and anyone who has ever had an online hash tool disagree with their terminal and needed to find out which byte was different.
How to use the tool
Choose Hash Text to hash typed input, or Hash File to checksum a file from disk.
In text mode, type or paste your input — the SHA-256 digest updates live above the input box, and an empty box shows the canonical empty-input digest e3b0c442…b855.
Pick the input encoding: UTF-8 (the default, and what sha256sum and Git use), UTF-16LE/BE, ISO-8859-1, Windows-1252, or raw hex/base64 bytes.
If you are reproducing a hash from a file that starts with a byte-order mark, tick 'Prepend a BOM'; leave it off to match command-line tools.
Tick 'Append a trailing newline' when reproducing echo "text" | sha256sum, which hashes an extra LF byte that echo -n does not add.
Copy the digest in lower-case hex, upper-case hex or base64 using the copy button next to each format.
In file mode, drop a file onto the drop zone — the progress bar shows percentage and MB/s while the file is streamed through SHA-256 in chunks.
Paste the publisher's checksum into 'Compare against an expected hash' for a green match / red mismatch verdict; bare hex, base64, a sha256sum line or a BSD SHA256 (file) = hash tag are all accepted.
Frequently Asked Questions
How do I generate a SHA-256 hash of text or a file?
In text mode, type into the input box — the 64-character hex digest appears immediately and updates on every keystroke; there is no Generate button to press. Choose an input encoding first if your source is not UTF-8, because the digest is taken over bytes, not characters. In file mode, drop a file onto the drop zone: the file is read in 4 MiB chunks and fed through a streaming SHA-256 implementation, so nothing is uploaded and nothing is held in memory in one piece. Both modes produce identical results to sha256sum, shasum -a 256 and Get-FileHash -Algorithm SHA256 on the same bytes.
What is the SHA-256 hash of an empty string?
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, or 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= in base64. It is the digest of zero bytes, which means it is also the checksum of every empty file — sha256sum /dev/null prints exactly that value. You will meet it constantly: as the payload hash for a body-less AWS SigV4 request, as a placeholder in content-addressed storage, and as the tell-tale sign that a pipeline hashed nothing at all. Many hash tools refuse empty input, so this tool deliberately allows it and labels the result.
Is it safe to hash sensitive data in this tool?
Yes. This tool runs entirely in your browser: text is hashed with the native Web Crypto API (crypto.subtle.digest) and files are hashed by a WebAssembly module loaded from this site. Your input never reaches a server, is never logged and is never stored. You can verify that claim without trusting us: open DevTools, switch to the Network tab, hash a large file, and observe that no request is made while it runs. The only network activity on the whole page is the initial page load plus the one-time WebAssembly fetch for file mode and MD5.
Should I use SHA-256 for password hashing?
No. SHA-256 is designed to be fast, and that is exactly wrong for passwords: a single modern GPU computes billions of SHA-256 hashes per second, so a stolen database of salted SHA-256 password hashes falls to brute force in hours for typical passwords. Use a deliberately slow, memory-hard password hash instead: Argon2id (see the [Argon2 tool](/tools/argon2-hash-generator-verifier/)), bcrypt with cost 12 or higher ([bcrypt tool](/tools/bcrypt-hash-generator-verifier/)), scrypt, or PBKDF2-HMAC-SHA256 with 600,000+ iterations where FIPS compliance forces your hand. SHA-256 belongs in fingerprints, signatures and integrity checks — never between an attacker and a user's password.
Why doesn't my UTF-16 hash match another tool's?
Almost always a byte-order mark. Many online tools silently prepend FF FE (UTF-16LE) or FE FF (UTF-16BE) before hashing, which adds two bytes and produces a completely different digest. SHA-256 of "abc" as UTF-16LE without a BOM is 13e228567e8249fce53337f25d7970de3bd68ab2653424c7b8f9fd05e33caedf; with the BOM it is aec4cd5ed4c05ed5cf9dea5a8b30f5e655ad87b937b36e3c059840ce3cf3642f. This tool never adds a BOM unless you tick the checkbox. The second suspect is endianness — UTF-16LE and UTF-16BE hold the same characters in opposite byte order, so they never agree.
Why does echo "abc" | sha256sum differ from hashing abc here?
echo appends a newline. "abc" is ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad, but "abc\n" — what echo actually pipes — is edeaaff3f1774ad2888673770c6d64097e391bc362d7d6fb34982ddf0efd18cb. Use printf '%s' abc | sha256sum or echo -n abc | sha256sum to hash three bytes, or tick this tool's 'Append a trailing newline' toggle to reproduce the four-byte version. The same class of bug bites text files: an editor that adds a final newline, or a Windows checkout that stores CRLF instead of LF, changes the file's checksum without changing a single visible character.
How do I verify a downloaded file's SHA-256 checksum?
Switch to Hash File, drop the download in, then paste the publisher's checksum into the compare box — a sha256sum line (hash, two spaces, filename) or a BSD SHA256 (file) = hash tag can be pasted whole. A green verdict means the bytes are identical. One caveat worth more than the checksum itself: a hash alone only proves the file was not corrupted in transit. If an attacker can replace the download they can usually replace the published hash too, so for real tamper protection verify the publisher's GPG signature over the checksum file, or rely on Authenticode/codesign.
Can SHA-256 be used with a secret key (HMAC)?
Yes — switch on 'Keyed mode: HMAC-SHA256'. HMAC combines a secret key with the message in a nested-hash construction (RFC 2104) and outputs a 256-bit authentication tag. It is what AWS SigV4 request signing, Stripe and GitHub webhook signatures, and JWT HS256 tokens all use. Use a 32-byte random key, and always compare tags with a constant-time comparison in production code to avoid timing leaks. For other key formats and output encodings, the [HMAC Generator & Verifier](/tools/hmac-generator-verifier/) covers more variants; the [Hash Identifier](/tools/hash-identifier/) helps when you do not know which algorithm produced a digest.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.