A SHA-256 hash is a fixed 256-bit digest calculated from the exact input bytes, and on Windows the SHA256 Hash Generator can calculate it in the current browser tab and return the result as 64 lowercase hexadecimal characters or standard padded Base64. To generate a SHA256 hash in Windows, open the generator, choose text or file input, enter or select the exact bytes, generate the digest, and copy the representation your reference system expects. Text mode encodes the string as UTF-8 before hashing, so spaces, accents, emoji, carriage returns, and a final newline are part of the input rather than presentation details. File mode hashes every selected byte, including headers, metadata, and line endings, making it a direct way to check a downloaded file against a vendor’s published checksum. The calculation stays in the current browser tab, and the application does not upload the selected content. Compare the complete result with a trusted reference obtained over HTTPS, a signed release, or another authenticated channel. A match confirms byte-for-byte integrity; it does not identify the creator. Use HMAC-SHA-256 for a shared secret or a digital signature for public-key origin verification.
What a Windows SHA-256 result contains
The result is a standard 32-byte SHA-256 digest. The tool renders those bytes in two equivalent representations: 64 lowercase hexadecimal characters and standard padded Base64. A digest is not an encrypted copy of the input, and it is not a key. It is a fixed-size value determined by the message or file bytes you submit.
SHA-256 belongs to the SHA-2 family specified by NIST FIPS 180-4. The page delegates the exact operation to the platform browser cryptography implementation. Internally, the algorithm pads the message, splits it into 512-bit blocks, expands each block into a 64-word schedule, and updates eight 32-bit working values; the final eight words form the 256-bit digest. The tool handles those details for you, while the source content and selected representation remain important to the result.
Choosing the right input mode and output format prevents a valid hash from being compared against the wrong thing. Use the following distinctions when deciding what to submit.
| Input mode | What is hashed | Byte-sensitive details | Typical Windows task |
|---|---|---|---|
| Text | Exact UTF-8 text | Spaces, accents, emoji, scripts, carriage returns, final newlines, and the displayed byte count | Compare a literal string with a text reference |
| File | Every selected file byte, up to 100 MB | Headers, embedded metadata, and line endings; no text decoding | Check a downloaded file or exact artifact |
Generate a SHA256 hash in Windows
- Open the generator. From your Windows PC, navigate to the SHA256 Hash Generator in the current browser tab. The calculation runs locally, and the application does not upload the selected content.
- Select the input type. In text mode, paste the exact content to verify. In file mode, choose the local file whose bytes need to be hashed. File input is capped at 100 MB, so use a selected file within that limit.
- Check the byte context. Text is encoded as UTF-8, and the displayed byte count is part of the result context. Preserve capitalization, accents, emoji, spaces, carriage returns, and any final newline. In file mode, do not decode and re-encode the artifact: headers, embedded metadata, and line-ending bytes are part of the input being hashed.
- Generate the SHA-256 digest. The tool passes the selected UTF-8 text or file bytes to the browser cryptography operation. Wait for the result associated with the current selection. The asynchronous job identity prevents an older file read or hash from replacing a newer selection.
- Copy the required representation. The output appears as 64 lowercase hexadecimal characters and as standard padded Base64. Both represent the same 32 bytes. Use the representation the other system expects, and copy the complete value rather than a prefix.
- Compare and record the result. Compare the complete digest with an authenticated reference and record SHA-256 beside the value. If the values do not match, check that both sides used the same bytes, including the same text encoding, line endings, and exact file rather than a similarly named file.
Text and file bytes must stay distinct
Text mode does not hash an abstract sequence of visible characters. It first encodes the string as UTF-8. Accented letters, emoji, and scripts outside ASCII can use multiple bytes, so text that looks similar can produce a different result when the source bytes differ. A pasted character that appears equivalent to another is not necessarily the same byte sequence.
Unicode normalization can also matter when text is being compared across tools. Preserve the source literal, and do not silently trim leading or trailing spaces or remove a final newline. Empty text is valid: the empty byte string has a standard digest beginning with e3b0c442. If a command-line utility gives a different value, check whether the shell appended a newline or whether the utility received text instead of file bytes.
File mode bypasses text decoding and hashes every selected byte, including headers, metadata, and line endings. That makes it the appropriate mode for a downloaded package or another byte-for-byte artifact. Compare the same selected file, not a converted copy, extracted portion, or differently named file. Text mode and file mode should not be mixed when the goal is to reproduce a known file digest.
Choose Hex or Base64 for the destination
Hex and Base64 are not two different SHA-256 algorithms. They are two presentations of the same 32 result bytes, selected for the system that will read the value. Lowercase is the tool’s normal Hex presentation; changing letter case changes presentation, not the underlying digest bytes. Base64 uses the standard padded form.
| Representation | Output | Best fit | Verification detail |
|---|---|---|---|
| Lowercase Hex | 64 hexadecimal characters | Manual checksum lists and systems that request SHA-256 Hex | Copy every character; letter case does not change the digest bytes |
| Standard Base64 | Padded Base64 text for the same 32 bytes | Build and deployment workflows that expect Base64 | Use it only when the destination specification requests Base64 |
Copy all 64 Hex characters when Hex is requested. The hash is not a reversible encoding, so a destination cannot reconstruct the source from either representation. Record the algorithm name alongside any stored digest so a 64-character value cannot later be confused with another format or an undocumented checksum.
Compare the full digest with an authentic reference
For a download, obtain the expected SHA-256 digest from the owner through HTTPS, a signed release, or another authenticated channel appropriate to the risk. Select the exact downloaded file, generate its digest, and compare the entire output. A match means that the two byte-for-byte artifacts match; it does not by itself prove that the file is safe or that its creator is authentic. A mismatch can result from the wrong file, an incomplete download, an encoding difference, or a line-ending difference.
- Download verification: Use a reference published by the software or file owner, then compare the complete generated value with that reference.
- Build and deployment: Hash the exact artifact required by the workflow and copy the Hex or Base64 representation that the receiving system expects.
- Artifact comparison: Generate a digest for two files only when the question is whether their bytes are the same; do not treat the result as a reverse lookup.
The authenticity of the reference matters just as much as the calculation. If an attacker can replace both a file and the checksum displayed beside it, recomputing SHA-256 confirms the attacker’s pair. It does not reveal that the pair was substituted. Use HMAC-SHA-256 when two systems share a secret and need message authentication, or a digital signature when a verifier must establish origin using a public key. SHA-256 answers an integrity question about bytes; it does not answer an identity question about their creator.
Know the limits and security boundary
Files are capped at 100 MB because the Web Cryptography digest interface used here receives the full byte buffer rather than a stream. For a much larger file, use a trusted streaming tool on the local machine instead of exhausting browser memory. The limit applies to the selected file, not to an assumption that a partial file produces a complete checksum.
All calculation takes place in the current browser tab, and the application does not upload the selected content. The displayed byte count gives useful context for text, while file mode includes every selected byte. The page intentionally performs only the raw standard digest; it does not add encryption, an HMAC calculation, a digital signature, or password-hashing behavior.
SHA-256 is a one-way hash, not encryption. There is no key and no supported reverse operation. It also does not authenticate who created an input. Use HMAC-SHA-256 when a shared secret is available to both parties, or use a digital signature when public-key verification is required. For ordinary integrity checks, the complete digest and an authentic reference are the important parts.
Do not store passwords by applying SHA-256 directly. Its speed is useful for integrity checks but also helps attackers test password guesses. Account systems should use a unique salt and a purpose-built password hashing function with calibrated memory and time cost. The generator is designed for the raw SHA-256 result, not for designing a password-storage scheme.
The page’s verification suite includes NIST and RFC examples plus independently cross-checked text, punctuation, UTF-8, and binary cases. It asserts the exact digest, fixed 32-byte size, and standard Base64 encoding. Those checks distinguish algorithm correctness from a self-consistent round trip, because a hash has no inverse. They improve confidence in the result, but they do not replace an authenticated reference.
For a deeper look, see How to Calculate a SHA-512 Hash and Verify Every Character.