What is the exact CMD command for SHA-256 on Windows?

Open cmd.exe and run certutil -hashfile "C:\path\to\file" SHA256. The command prints the 64-hex-character digest split into four groups; strip the spaces before pasting the value into a verification step.

Why does my CMD result not match the value from another tool?

Almost every mismatch is a byte-level difference rather than an algorithm difference. Check for an added trailing newline, a text-encoding mismatch (UTF-8 vs UTF-16 or ANSI), Unicode normalization differences, or compare file bytes directly instead of pasted text.

Can CMD hash a string, not just a file?

CertUtil only hashes files. To hash a string from CMD, call PowerShell in one line: powershell -NoProfile -Command "[BitConverter]::ToString([System.Security.Cryptography.SHA256]::Create().ComputeHash([System.Text.Encoding]::UTF8.GetBytes('your string'))).Replace('-','')". The result is the same 64-hex-character digest you would get from a file path.

Is the SHA-256 digest reversible or encrypted?

No. SHA-256 is a one-way hash function with no key. Given the digest, there is no supported operation that recovers the original input. For message authentication between two parties that share a secret, use HMAC-SHA-256 instead.

How large a file can the browser tool hash?

The SHA256 Hash Generator accepts up to 100 MB per file. Larger files should be hashed with a streaming tool on the local machine such as PowerShell's Get-FileHash, which processes the input in chunks instead of loading it into a single buffer.

SHA256 Hash in Windows CMD: Commands and Cross-Check

The Windows command prompt can generate a SHA-256 hash with no extra software: open cmd.exe, run certutil -hashfile "path\to\file" SHA256, and copy the 64-character hex digest from the output. SHA-256 is the 256-bit member of the SHA-2 family specified by NIST FIPS 180-4, and the same algorithm is also reachable from PowerShell, from File Explorer's "File Hashes" context menu on recent Windows 10 and 11 builds, and from a browser-based tool such as the SHA256 Hash Generator. The CMD path matters because scripts, build pipelines, and download verification steps still run from a plain command prompt on many machines, and because the built-in command avoids installing third-party utilities on locked-down workstations. The output is always a fixed 32-byte digest, represented as 64 hexadecimal characters, that acts as a deterministic, one-way fingerprint of the exact bytes read. Identical input bytes produce identical digests; a single added space or newline changes the fingerprint, which is why a CMD output sometimes looks wrong even when both sides are running the same algorithm.

how to generate sha256 hash in windows cmd — SHA256 Hash in Windows CMD: Commands and Cross-Check

What "Generate a SHA256 Hash in Windows CMD" Actually Means

The task is to feed a file or string into the SHA-256 algorithm and read back a deterministic 256-bit digest. The digest is the same on every run, on every machine, and across operating systems, provided the input bytes are identical. The hard part is the byte-level part: spaces, carriage returns, line endings, and UTF-8 encoding choices all become part of the input, so the same logical text can produce different digests if the underlying bytes differ. RFC 6234 documents the same algorithm under the name SHA-256 and is the reference for cross-platform interop.

In practice, two flavors of input come up in CMD workflows. The first is a file on disk: an ISO, an installer, a release zip. The second is a short text snippet, such as a token, a build identifier, or a command string, that someone wants a quick fingerprint of. CMD handles the first case directly with CertUtil; for the second case, most users either pipe the text through PowerShell or switch to a browser tool that accepts text and files interchangeably.

The Built-in CMD Command for SHA-256: CertUtil

CertUtil ships with every supported Windows version and exposes several hash algorithms through the -hashfile flag. To compute SHA-256 of a file, open cmd.exe, navigate to the file's folder, and run:

certutil -hashfile "C:\Users\you\Downloads\installer.msi" SHA256

The command prints a header, the 64-hex-character digest split by spaces into four groups, and a "CertUtil: -hashfile command completed successfully" footer. The spaces in the output are decorative; strip them before pasting into a verification script. The algorithm name is case-insensitive, so SHA256, sha256, and Sha-256 all map to the same digest operation.

PowerShell offers the same result with Get-FileHash -Algorithm SHA256 "C:\path\to\file", which prints lowercase hex without spaces. PowerShell can also be called from CMD in one line when a script has to stay inside a .bat file:

powershell -NoProfile -Command "Get-FileHash -Algorithm SHA256 'installer.msi' | Select-Object -ExpandProperty Hash"

For text input rather than a file, PowerShell's [System.Security.Cryptography.SHA256]::ComputeHash combined with a UTF-8 encoder is the usual CMD-adjacent approach. Each new line, leading space, or missing BOM changes the result, so byte-precise verification is harder than with a file path.

Generating the SHA-256 With the SHA256 Hash Generator

A browser tool covers the cases CMD handles awkwardly: text mode, Unicode characters, and quick checks against a vendor's published checksum without typing a path. The SHA256 Hash Generator runs the same FIPS 180-4 algorithm inside the current browser tab through the platform cryptography implementation, so the selected content never leaves the machine. The steps are:

Pick the text or file input mode that matches your source.
For text, type or paste the exact string. The tool encodes it as UTF-8 first, so the displayed byte count already reflects accented letters, emoji, or any non-ASCII script that uses more than one byte per character.
For a file, choose a local file up to 100 MB. The tool hashes every selected byte, including headers and metadata, exactly as they sit on disk.
Read the digest. The Hex value is 64 lowercase characters; the Base64 value is the standard padded encoding of the same 32 bytes.
Copy the representation the receiving system expects and paste it into the comparison field or a text file.
Compare the complete digest, character by character, with the authenticated reference. A matching prefix is not a match.

As a known test vector, the SHA-256 of the empty string (zero bytes of UTF-8 text) is e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, and the same 32 bytes encode in Base64 as 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=. Any tool that reports a different value for empty input is hashing something other than zero bytes.

Why CMD and Browser Tool Output Can Differ

When two correct SHA-256 implementations disagree, the algorithm is rarely the cause; the input bytes are. The table below lists the most frequent mismatches a CMD user sees when comparing against a vendor's published digest or against a browser tool.

Symptom	Common cause	Fix
Last two hex characters are wrong	A trailing newline was added by the shell or by the text editor	Strip the final newline, or compare file-to-file instead of file-to-text
Entire digest differs for "the same" string	Text was hashed as UTF-16 or as an ANSI codepage instead of UTF-8	Re-encode the string as UTF-8 before hashing, and check that emoji or accents survive the round trip
Digest of pasted text changes when re-entered	Unicode normalization form (NFC vs NFD) or invisible characters	Hash file bytes directly, or use a tool that exposes the byte count alongside the digest
CertUtil output is uppercase, tool output is lowercase	Letter-case of the hex representation	Compare case-insensitively; case changes presentation, not the underlying digest bytes
Vendor's hex digest is 40 characters long	Reference is SHA-1, not SHA-256	Recompute with the algorithm the vendor actually published and store the algorithm name with the value

The same byte-level rules apply whether the digest came out of CertUtil, PowerShell, or the browser tool. The algorithm is deterministic, so a mismatch always points back to a difference in the bytes that were hashed.

Hex vs Base64: Choosing the Representation the Other Side Expects

Every SHA-256 digest is 32 bytes. Two encodings of those bytes appear everywhere: 64 lowercase hex characters, and 44 standard Base64 characters including one = pad. CertUtil prints hex with internal spaces; PowerShell prints hex without spaces; the SHA256 Hash Generator prints both forms so neither side has to convert on the fly. Both encodings represent the same number, so changing presentation does not change the underlying digest. If the receiving system expects Base64, paste the Base64 value; if it expects hex, paste the hex value. Mixing the two always fails verification even though the digest is identical.

For a wider walk-through that includes PowerShell and the File Explorer option, see the companion guide on generating a SHA256 hash in Windows; for a JavaScript-focused path that uses the same Web Crypto API behind the browser tool, the JavaScript SHA-256 guide covers the equivalent code.

When the Browser Tool Is the Better Cross-Check

Even when CMD produces the digest a script needs, running the same bytes through a second independent tool is a fast way to catch byte-level mistakes. The browser tool is well suited for this because it runs the algorithm locally, accepts both files and text, and prints the byte count alongside the digest. Three situations favor it as a cross-check:

The CMD input is text rather than a file. Pasting the same string into the tool and confirming the byte count matches the expected digest's pre-image is faster than debugging a PowerShell encoder.
The vendor published a Base64 digest. Copying from the tool avoids manual hex-to-Base64 conversion.
The file is small enough to fall under the 100 MB cap and the user wants to verify a download on a machine where installing utilities is restricted.

For files above 100 MB, the Web Cryptography digest interface used by the browser receives the full byte buffer rather than a stream, so a streaming tool on the local machine — the built-in Get-FileHash, for example — is the safer choice. As with any integrity check, the comparison is only as trustworthy as the reference digest. If an attacker can replace both a file and the checksum displayed beside it, recomputing SHA-256 will confirm the attacker's pair. Fetch reference hashes over HTTPS from the vendor's signed release page, through a signed release artifact, or through another authenticated channel appropriate to the risk. SHA-256 is a one-way function with no key and no supported inverse, so it verifies bytes but never authenticates origin by itself; for that, HMAC-SHA-256 or a digital signature is the appropriate primitive.