SHA-256 always produces a fixed 256-bit (32-byte) digest for any input, displayed as 64 lowercase hexadecimal characters or as standard padded Base64, regardless of the size of the original message. The same UTF-8 text or the same file bytes will yield the identical digest on every conformant implementation, because SHA-256 is specified down to the bit by NIST FIPS 180-4. In JavaScript, that digest can be produced in three practical ways: by calling the platform Web Crypto API through SubtleCrypto.digest with the algorithm string "SHA-256", by importing a third-party pure-JavaScript library that re-implements the compression function in user space, or by handing the exact bytes to a local browser tool and copying the result. All three approaches must agree on what counts as "the input": a string of characters is not the same as a sequence of bytes, and a single stray newline, an emoji, or a Unicode normalization difference will produce a different digest. The sections below cover what SHA-256 actually computes, how the three JavaScript paths differ, how to run a digest through the SHA256 Hash Generator, and the byte-level pitfalls that most often cause "my hash does not match" reports.
What SHA-256 actually computes
SHA-256 belongs to the SHA-2 family of hash functions, with the full algorithm published in NIST FIPS 180-4. The "256" refers to the length of the digest in bits, so every output is exactly 32 bytes; 32 bytes rendered as hex is 64 characters, and 32 bytes rendered as standard Base64 is 44 characters of padded text. The function is deterministic: identical input bytes produce identical output bytes on every conformant implementation, and there is no key, salt, or random element in the raw algorithm.
Internally, the algorithm pads the message to a multiple of 512 bits, splits the padded bytes into 512-bit blocks, and processes each block through 64 rounds that update eight 32-bit working variables. After every block has been processed, those eight working variables are concatenated to form the final 256-bit digest. The per-round constants and initial values are fixed by the standard, which is why the empty byte string always produces the exact digest e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. No conformant implementation may produce any other value for that input, and the test vectors are independently checked against the NIST CAVP Secure Hashing suite.
Three ways to generate SHA-256 in JavaScript
Modern JavaScript environments expose the digest through the Web Crypto API, which delegates the math to the underlying platform. The standard call is asynchronous and returns an ArrayBuffer:
// Web Crypto API (browser and modern Node.js with globalThis.crypto)const bytes = new TextEncoder().encode(value);const digest = await crypto.subtle.digest('SHA-256', bytes);// digest is an ArrayBuffer of exactly 32 bytes
This is the recommended path whenever it is available, because the underlying implementation is shared with the operating system and has been validated against the published test vectors. A second path is a third-party JavaScript library such as js-sha256, hash-wasm, or a hand-rolled implementation; these run in pure user space and are useful in environments without SubtleCrypto or when the SHA-256 transform must run synchronously on the main thread. A third path is to hand the bytes to a local browser tool such as the SHA256 Hash Generator, which performs the same SubtleCrypto call on the exact UTF-8 text or selected file bytes and shows both the 64-character hex and the standard padded Base64.
| Approach | Where it runs | Returns | Best for |
|---|---|---|---|
| Web Crypto SubtleCrypto.digest | Browser tab / modern Node | ArrayBuffer of 32 bytes | Production code, tests, signed releases |
| Pure-JS library (js-sha256, hash-wasm) | User space JavaScript | Hex string or byte array | Legacy browsers, sync code, embedded JS |
| SHA256 Hash Generator tool | Browser tab | Hex and Base64 strings | Manual verification, one-off checksums |
All three are correct on the same input bytes; the choice depends on whether you need the result inside a script, inside a build, or inside a human inspection. None of them should ever claim to be more "secure" than the others, because SHA-256 is the same algorithm in every case.
Generate a SHA-256 hash with the local tool
The fastest path when you need an exact SHA-256 digest for a string of text or a downloaded file is to feed the bytes into the SHA256 Hash Generator and copy the result. The tool exposes the same digest operation that SubtleCrypto would run in your own code, with the input controls limited to text or a file.
- Open the SHA256 Hash Generator in your browser tab.
- Choose text mode for UTF-8 input or file mode for raw bytes, then enter or select the exact content you want to verify. The tool encodes text as UTF-8 before hashing, so accented letters, emoji, and non-ASCII scripts contribute their full multi-byte UTF-8 representation.
- Click the generate action. The digest appears as 64 lowercase hexadecimal characters and as standard padded Base64; both representations describe the same 32 result bytes.
- Copy the representation that the system you are verifying against expects. Hex letter case is a presentation choice and does not change the underlying bytes; matching lowercase hex with uppercase hex still describes the same digest.
- Compare the complete output, not a prefix, with the reference value. A single character difference means the input bytes differed; a perfect match means the bytes were identical.
The empty string is a valid input and produces the well-known SHA-256 digest beginning e3b0c442, which is a quick way to confirm the tool is wired to the same FIPS 180-4 algorithm that your own SubtleCrypto call uses. Files are capped at 100 MB because the Web Cryptography digest interface receives the full byte buffer rather than a stream; for larger artifacts, hash locally with a streaming command-line tool instead of exhausting browser memory.
Why the byte representation matters
SHA-256 operates on bytes, not characters. When you type "héllo" into a text field and generate a digest, the tool first encodes those characters as UTF-8, producing five bytes for the visible word plus one more for the accented é, then digests those six bytes. The same word pasted into a tool that interprets the input as Latin-1 will digest only five bytes and return a different value. File mode avoids the ambiguity entirely: it bypasses text decoding and hashes every selected byte, including invisible header bytes, embedded metadata, and the exact line-ending bytes (CR, LF, or CRLF) that the file actually contains.
Several subtle sources of mismatch come up repeatedly in JavaScript projects:
- Trailing newline. A shell command such as echo "abc" typically appends a newline before piping to a hash utility, while a pasted string usually does not. The two digests differ by one byte.
- Unicode normalization. Some characters have more than one valid UTF-8 sequence. Composed (NFC) and decomposed (NFD) forms of "é" produce different byte sequences and therefore different digests.
- Encoding mismatch. A file saved as Windows-1252 or UTF-16 contains different bytes from the same text encoded as UTF-8. Hashing the wrong encoding will produce a value that does not match a reference computed in UTF-8.
- Byte order mark. A UTF-8 BOM (EF BB BF) at the start of a file is a real byte. Removing or preserving it changes the digest.
The rule is simple: preserve the exact bytes, then hash. If a reference value exists, generate it from a known-clean input, or copy the bytes out of the file with a tool that reports the byte count alongside the digest. Spaces, carriage returns, and final newlines are also bytes and can change the result, so treat whitespace as significant.
Verifying a digest safely
A matching SHA-256 digest is meaningful only when the expected value itself is authentic. If an attacker can replace both a downloaded file and the checksum displayed beside it, recomputing SHA-256 will simply confirm the attacker's pair. Obtain reference hashes over HTTPS from the software owner, through a signed release manifest, or through another authenticated channel appropriate to the risk, and record the algorithm name alongside any stored digest so a 64-character SHA-256 value cannot later be confused with a different format or an undocumented checksum.
SHA-256 also does not authenticate who created an input. If two systems share a secret and need message authentication, the right tool is HMAC-SHA256, which mixes the secret into the compression function and resists length-extension attacks. A digital signature is appropriate when a verifier must establish origin using a public key. Plain SHA-256 is the right choice for integrity checks, deduplication, and build-pipeline checksums, but not for proving authorship.
SHA-256 is not encryption and not a password hash
SHA-256 is a one-way function: there is no key and no supported reverse operation, so it cannot recover the original input. It is also too fast for password storage. Its speed is exactly what makes it useful for integrity checks, and exactly what lets an attacker test billions of password guesses per second against a stolen database. Account systems should use a unique random salt per user and a purpose-built password hashing function with calibrated memory and time cost, such as Argon2id, scrypt, or bcrypt. For passwords that need to be generated in the first place, use a Password Generator backed by a cryptographically secure RNG, and check the resulting value against a Password Strength Checker rather than against the length of its SHA-256 digest.