SHA-256 produces a fixed 256-bit digest — 64 lowercase hexadecimal characters or 44 standard Base64 characters — for the exact bytes of any file you select. When you generate a SHA256 hash for a file, the algorithm reads every byte of that file, including invisible headers, embedded metadata, and line-ending bytes, and reduces them to a 32-byte fingerprint that no two different files share in practice. The result is small enough to paste anywhere, yet changes completely if even a single byte of the input changes. The SHA256 Hash Generator performs this computation in your current browser tab using the platform cryptography implementation specified by NIST FIPS 180-4, so the file you select never leaves your machine. This makes the operation both reproducible and private: the digest you copy is the digest the algorithm computes, with no intermediate server, no upload step, and no alteration of the original file. Understanding what that digest represents — and what it does not represent — is the first step toward using it well.
What a SHA-256 File Hash Actually Represents
A SHA-256 file hash is a deterministic, one-way reduction of file bytes to a fixed-size identifier. Three properties make it useful for file integrity work.
First, the digest is fixed in length. Every SHA-256 output is exactly 32 bytes, no matter whether the input file is 4 KB or 4 GB. That uniformity is what lets a 64-character Hex string fit in a database column, a release page, or a build log alongside millions of other files.
Second, the digest is deterministic. The same sequence of input bytes always produces the same sequence of output bytes. If you hash a file on Monday and hash the same file again on Friday, with no modification in between, both operations must produce identical 64-character Hex strings. Any deviation means the bytes have changed.
Third, the digest is one-way. There is no key, no inverse operation, and no supported way to recover the original file from its SHA-256 digest. SHA-256 is not encryption; it is a fingerprint function. SHA-256 belongs to the SHA-2 family specified by NIST FIPS 180-4, which defines the exact padding, block, and compression rules the implementation must follow.
The tool delegates that exact operation to the browser: it pads the input 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. Tests assert this exact digest against NIST examples, RFC examples, and independently cross-checked text, punctuation, UTF-8 and binary cases, so the algorithm itself is verified, not merely self-consistent.
How to Generate a SHA-256 Hash for a File
- Open the SHA256 Hash Generator and switch to the file input mode rather than the text input mode.
- Select the file you want to hash from your local disk. The tool reads up to 100 MB of bytes directly through the browser, and nothing is uploaded.
- Confirm the displayed byte count matches your expectation. The byte count is part of the verification context, not a cosmetic detail, because it tells you which exact sequence of bytes the digest covers.
- Generate the SHA-256 digest and wait for the calculation to complete. The asynchronous job identity prevents an older file read or hash from replacing a newer selection.
- Copy either the 64-character lowercase Hex output or the standard padded Base64 — whichever format the reference system expects.
- Compare the complete output character by character against the trusted reference. Never rely on a prefix match, and treat case strictly if the reference itself is case-strict.
If you are also hashing the file with a command-line utility, make sure that shell pipeline did not silently append a newline, and confirm both sides read the same byte sequence from the same file. A mismatch on either point produces a digest that differs from yours even when the source files appear identical.
Hex vs Base64 Output for File Checksums
The 32 result bytes can be displayed in two equivalent representations. Hex is the conventional choice for human-facing references such as vendor download pages, build manifests, and Git commit hashes, because every character is a digit or a lowercase letter and a quick visual scan is enough to detect typos. Base64 is denser, which makes it attractive for APIs, JSON payloads, and compact logs where every character costs bandwidth. The table below compares the two formats.
| Property | Hex output | Base64 output |
|---|---|---|
| Output length | 64 characters | 44 characters |
| Alphabet | 0–9 and a–f | A–Z, a–z, 0–9, +, /, with = padding |
| Case sensitivity | Lowercase by convention; identical digest either way | Strictly case-sensitive |
| Common use | Download pages, build manifests, Git commit hashes | APIs, JSON payloads, compact logs |
| Verification style | Visual, character by character | Faster to copy and parse |
Both formats represent the same 32 bytes, so picking one does not change what the algorithm computed. Copy the representation the other system expects; changing Hex letter case changes presentation, not the underlying digest bytes.
Matching a File Hash to a Trusted Reference
The value of a file hash is only as strong as the authenticity of the reference you compare it against. A matching digest is meaningful only when the expected value itself is authentic. If an attacker can replace both a file and the checksum displayed beside it, recomputing SHA-256 will confirm the attacker's pair rather than expose it.
To keep the comparison trustworthy, obtain reference hashes over HTTPS from the file's owner, through a cryptographically signed release, or through another authenticated channel appropriate to the risk. For an open-source distribution, that usually means the checksums.txt file published alongside the binary on the project's official download mirror, signed by a maintainer key you can verify out of band. For a vendor-supplied installer, the reference often appears in signed release notes or in a checksum manifest fetched over TLS.
Once you have the authenticated reference, paste the complete digest — not a prefix — and compare it character by character. A one-character mismatch means the bytes are different, even if the prefix looks the same. For a deeper walkthrough of this comparison workflow, see the matching-a-reference guide.
Record the algorithm name alongside any stored digest. A bare 64-character string could be SHA-256, a truncated SHA-512, or an undocumented custom checksum, and without the label you have no way to tell later which algorithm produced it.
Why File Bytes — Not File Names — Determine the Result
A common misunderstanding is that a file's name, extension, or location influences its hash. It does not. File mode bypasses text decoding entirely and hashes every selected byte, including headers, embedded metadata, and line-ending bytes. Renaming installer.exe to installer.bak does not change the digest. Copying the file from one folder to another does not change the digest. The only thing that changes the digest is a change in the underlying bytes.
That byte-level fidelity also explains why text-mode settings can produce a different hash for what looks like the same content. In text mode, the tool first encodes the string as UTF-8, so a multi-byte character such as é produces a different digest than the ASCII letter e followed by the combining acute accent. Spaces, Unicode normalization forms, carriage returns, and final newlines are all bytes and can change the result. When you switch to file mode for a file, those text-mode subtleties disappear because the tool hashes the bytes the file already contains.
Files are capped at 100 MB because the browser digest operation receives the full byte buffer rather than a streaming interface. For much larger files, use a trusted streaming tool on the local machine instead of exhausting browser memory. The tool also intentionally performs only the raw standard digest; it does not wrap the input in an HMAC construction, sign it with a private key, or apply a password-hashing function. Those are different operations with different guarantees, and choosing the right one matters as much as choosing the right hash.