SHA-256 is a 256-bit cryptographic digest defined by NIST FIPS 180-4, and it can be produced in one line with OpenSSL's dgst -sha256 subcommand or computed locally in the browser from the exact same UTF-8 or file bytes. The OpenSSL route suits scripts, CI pipelines, and remote servers where you want a known, reproducible tool with predictable output formatting; the browser route suits quick spot checks, downloads you want to verify without firing up a terminal, and cases where pasting a string is faster than echoing it through a shell. Both paths produce the same fixed 32-byte digest for the same input bytes, rendered either as 64 lowercase hexadecimal characters or as standard padded Base64. The catch is to make sure both sides see byte-for-byte identical input — that means matching line endings, the same UTF-8 encoding, and no extra trailing newline added by your shell — and that the reference hash you compare against was published over an authenticated channel rather than scraped from an unrelated mirror.
The OpenSSL Commands Behind a SHA-256 Digest
The standard OpenSSL invocation for a SHA-256 hash of a file is a single line. Open a terminal in the directory that holds the file and run openssl dgst -sha256 filename.zip. The output prints the algorithm name and the 64-character hex digest in a form like (stdin)= digest or filename.zip= digest. To strip the filename prefix in scripts, add -r to print a single space-separated line: openssl dgst -sha256 -r filename.zip. OpenSSL also accepts the shortened alias openssl sha256 filename, which is equivalent for FIPS-mode builds and easier to remember.
To hash a literal string instead of a file, pipe echo into the same command. The critical flag is -n, which tells echo not to append a trailing newline — that single byte will completely change the digest. The command echo -n "hello world" | openssl dgst -sha256 returns the well-known test vector b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9. Drop the -n and the appended newline shifts the entire output to a totally different 64-character value, which is exactly why command-line digests so often surprise newcomers who compare against a checksum they copied from a webpage. When you must avoid any newline at all, use printf '%s' "your string" | openssl dgst -sha256, which produces byte-for-byte identical output across shells.
For binary or downloaded artifacts, the same openssl dgst -sha256 call hashes every byte exactly as stored, including headers, metadata, and CRLF line endings if the file was saved that way. There is no streaming limit on the CLI side; OpenSSL will happily hash multi-gigabyte files in chunks. If you want to verify a published signature rather than just a checksum, pair the digest with openssl dgst -sha256 -verify publickey.pem -signature file.sig file, or compare a separately downloaded signature file using the appropriate algorithm. For day-to-day integrity checks against a published hex string, the bare digest command is enough.
Generate a SHA-256 Hash in Your Browser
When a terminal isn't available — on a locked-down workstation, on a shared computer, or simply when pasting text is faster than typing a shell command — the SHA256 Hash Generator reproduces the same NIST-defined digest directly in the browser tab using the platform cryptography implementation. Everything runs locally, nothing is uploaded, and the result panel shows the byte count alongside the hex and Base64 outputs so you can sanity-check exactly what got hashed.
- Open the SHA256 Hash Generator and choose text mode or file mode.
- Type or paste the exact UTF-8 string, or select the local file whose bytes you want to hash.
- Generate the digest and read the byte count shown beside the result — it should match the bytes you intended to hash.
- Copy either the 64-character lowercase Hex value or the standard padded Base64 string, whichever format the receiving system expects.
- Compare the complete output, character by character, with the reference hash you obtained from a trusted source.
The tool caps file inputs at 100 MB because the underlying Web Cryptography digest interface receives the entire byte buffer in one call rather than streaming chunks. For larger artifacts, fall back to a streaming CLI tool on the local machine instead. Text mode is not character-based: the page first encodes the string as UTF-8, so accented letters, emoji, and scripts outside ASCII each contribute the right number of bytes to the count you see on screen. File mode bypasses text decoding entirely and hashes every selected byte — including hidden metadata, embedded headers, and line-ending bytes — which is why it matches the output of openssl dgst -sha256 on the same file.
Why Browser and CLI Results Sometimes Differ
Both paths implement the same FIPS 180-4 compression function, so the digest only changes when the input bytes change. When a browser tool disagrees with an OpenSSL command, the cause is almost always a hidden byte-level difference in the input rather than an algorithm mismatch. The table below lists the usual suspects in order of how often they bite people.
| Common cause | What actually happens | How to fix it |
|---|---|---|
| Shell appends a trailing newline | Echo adds 0x0A, shifting every block boundary in the compression function | Use echo -n or printf '%s' "your string" |
| Text encoding mismatch | One side treats the string as Latin-1, the other as UTF-8 | Confirm both tools read UTF-8 and inspect the displayed byte count |
| Unicode normalization forms | Visually identical strings with different code-point bytes (NFC vs NFD) | Normalize both sides to NFC before hashing |
| File vs text confusion | File mode ignores text decoding and keeps raw bytes | Hash raw bytes for binaries, encoded UTF-8 for text |
| Invisible whitespace or BOM | Extra spaces, tabs, or a UTF-8 BOM (EF BB BF) sneak in | Strip BOM, trim whitespace, then re-hash |
Whenever a digest disagrees with a reference, fix the input first and re-run both tools. A mismatch is information about the bytes, not about the algorithm — and once the inputs agree, OpenSSL and the browser generator will agree too.
Hex and Base64: Two Views of the Same 32 Bytes
A SHA-256 digest is always exactly 32 bytes, or 256 bits. The choice between Hex and Base64 is purely a presentation decision made by the software producing the checksum; the underlying bytes are identical and either encoding can be losslessly converted back to the other.
| Property | Hex | Base64 |
|---|---|---|
| Output length | 64 characters | 44 characters including the equals padding |
| Character set | Digits 0–9 and lowercase a–f | A–Z, a–z, 0–9, plus, slash, and equals padding |
| Case-sensitive when comparing | Yes | Yes |
| Underlying bytes represented | 32 bytes | 32 bytes |
| Common contexts | Git commit hashes, ISO checksums, package-manager digests | JWT segments, API request bodies, compact token formats |
When you copy a digest out of the SHA256 Hash Generator, pick the representation the consumer expects. Hex letter case changes presentation but never the underlying byte values, so most tools accept either uppercase or lowercase and produce the same match. Receiving systems that compare in constant time usually lowercase both sides first; if yours doesn't, paste exactly the case you copied and avoid silent typos.
A Matching Digest Only Proves Bytes Matched
A SHA-256 comparison answers exactly one question: did this 32-byte digest come from input bytes that, after the SHA-2 compression, produce these 32 bytes? It does not prove who created the file, when it was created, or why. The NIST CAVP Secure Hashing suite verifies the algorithm against known vectors; what it cannot verify is the provenance of the digest you compared against.
If an attacker can replace both a download and the checksum displayed next to it, recomputing SHA-256 will still match — but only because both pieces were swapped together. To make a digest comparison meaningful, fetch the reference hash from a channel the attacker cannot rewrite: the vendor's site served over HTTPS, a signed release announcement, a package-manager manifest, or a checksum file delivered alongside a PGP signature. For high-stakes releases, verify the signature file first and only then trust the digest it lists.
For applications that need to know who produced a message, SHA-256 is the wrong primitive. Use HMAC-SHA-256 when two parties share a secret and need to authenticate each message, or a digital signature with a public key when a verifier must establish origin. Password storage also belongs in a different category: the raw SHA-256 of a password is fast for attackers to guess, so production systems should use a unique per-user salt and a purpose-built memory-hard function rather than this raw digest.
Picking the right tool depends on context. OpenSSL remains the standard for scripts and server-side automation where the command line is already trusted and you want to hash large files without size limits. The SHA256 Hash Generator covers the cases where reaching for a terminal is overhead — pasting a copied string, verifying a download from a public computer, or showing a colleague the exact digest of a snippet. Both produce the same 32-byte answer when the input bytes match, and that property is the only one worth comparing.
Related reading: Devglan SHA-512 Hash Generator: Full 512-Bit Digest Locally.
Related reading: Generate a SHA-1 Hash on Linux for Checksum Matching.