SHA-256 Hash Generator

What a hash is, and how it differs from encryption

A hash function takes an input of any length and returns a fixed-length value called a digest. SHA-256 always returns 64 hexadecimal characters whether you feed it one letter or a 4 GB disk image. Three properties make the result useful:

• One-way: you cannot work backwards from the digest to the input. This is the biggest difference from encryption.
• Deterministic: the same bytes always produce the same digest, on any machine, in any year.
• Avalanche effect: change one bit of the input and roughly half the output bits flip, so a near miss looks nothing like a hit.

Together those properties make a hash a compact fingerprint: it tells you whether two pieces of data are byte for byte identical without either side having to send the data itself. The SHA-2 family here, which covers SHA-256, SHA-384 and SHA-512, is defined in the NIST Secure Hash Standard. SHA-3, built on the Keccak design, was standardized in 2015 as a structurally different backup in case a weakness is ever found in SHA-2.

Hashing vs encryption vs encoding

These three get mixed up constantly, and the difference is what happens on the way back:

• Hashing: one-way, no key, nothing to undo. SHA-256 on an installer tells you whether the bytes are the ones the publisher shipped.
• Encryption: two-way, with a key. AES turns a message into ciphertext that the holder of the key can turn back into the message.
• Encoding: two-way, no key, purely a change of format. Base64 exists to move binary data through channels that only accept text.

Confusing them has real costs. Storing passwords as bare SHA-256 and calling them encrypted leaves them open to offline guessing at enormous speed, and treating Base64 as protection hides data from nobody, since a single command reverses it. This page does only the first of the three, and only in the forward direction.

Which of the four algorithms you need

All four are computed at once, so there is nothing to choose before you start. Match whichever one the other side published; when nobody has specified anything, use SHA-256.

• SHA-1 (40 characters): broken for security purposes since a practical collision was published in 2017. Keep it for reading values from older download pages and Git object ids, not for new work.
• SHA-256 (64 characters): the default almost everywhere, including TLS certificates, package manager lock files, container image digests and the checksum line on a release page.
• SHA-384 (96 characters): uncommon on its own, but it appears in TLS cipher suites and in subresource integrity attributes for scripts and stylesheets.
• SHA-512 (128 characters): the same security margin as SHA-256 for practical purposes, and often faster on 64-bit hardware, which is why some projects publish it for large archives.

The character count is the giveaway. Count the length of the checksum you were given and the box with the matching length is the one to compare against. If it has 32 characters it is MD5, which the browser cannot compute; see the platform notes below.

How to check a download against its published checksum

1. Copy the checksum from the publisher’s own site and note which algorithm it is labeled with. Taking it from a mirror or a forum post defeats the purpose, because whoever tampered with the file could publish a matching value there too.
2. Press Choose file above and select the file you downloaded. It is read into this tab and hashed locally; nothing is uploaded.
3. Wait for the four values to appear, find the box whose algorithm matches the published one, and press the copy button in its corner.
4. Compare the two strings with a search box or a diff, not by eye. The avalanche effect guarantees that a single changed byte produces a completely different value, but a human scanning 64 characters will still miss a swapped pair in the middle.
5. If they do not match, download again from the official source and rehash before you install or unpack anything.

Once a file is selected the text box is set aside. To go back to hashing text, press the cross next to the file name or simply edit the text box again.

How to tell whether two pieces of text are identical

1. Paste the first piece into the text box and copy the value from one of the four boxes.
2. Clear the box, paste the second piece, and read the same algorithm. Identical strings mean the two inputs are identical down to the byte.
3. When the values differ and you cannot see why, the difference is almost always invisible: trailing spaces, Windows CRLF against Unix LF line endings, a byte order mark at the start of a file, a non-breaking space pasted from a web page, or curly quotes substituted by a word processor.
4. For whole config files or documents, use Choose file rather than pasting. Copying through the clipboard can silently change indentation, line endings or trailing whitespace before the text ever reaches the box.

Getting the value where you need it

• Copy: every box has a copy button in its top corner, and it copies the whole value with nothing appended.
• Case: this page outputs lowercase hexadecimal with no spaces or separators. Some sites publish uppercase, and a few insert spaces every few characters. Those are the same value. Compare case-insensitively and strip whitespace before you decide something is wrong.
• Into a document or ticket: wrap the value in a code block or backticks. Chat clients and issue trackers otherwise wrap, hyphenate or autocorrect the string, and someone copying it back out gets a value that will never match.
• Into a checksum file: the convention used by sha256sum is one line per file containing the value, two spaces and the filename. A file in that format can be verified later with sha256sum -c.
• On a phone: the value is selectable text, but selecting all 128 characters of a SHA-512 by dragging is error-prone. Use the copy button.
• Into HTML: subresource integrity attributes want base64, not hex, so a value copied from here cannot be pasted into an integrity attribute directly.

What the browser can compute, and the command per system

Why there is no MD5

The browser’s native crypto.subtle API does not offer MD5. Collisions against MD5 have been producible on ordinary hardware since the mid 2000s, so it is unsuitable for anything security related, and the Web Crypto specification does not list it among the supported digests. This page uses only that native API and pulls in no third-party hashing library, so the four SHA algorithms are what it can offer. If a vendor still publishes only an MD5, use one of the local commands below.

The same value from a terminal

• macOS: shasum -a 256 file, or openssl dgst -sha256 file. md5 is also present.
• Linux: sha256sum file, with sha1sum, sha384sum, sha512sum and md5sum alongside it.
• Windows: PowerShell has Get-FileHash -Algorithm SHA256 file, and certutil -hashfile file SHA256 works from the classic command prompt.
• Node.js: crypto.createHash('sha256') supports more algorithms than the browser does, including MD5 and the SHA-3 family, because it draws on OpenSSL.
• Python: hashlib.sha256(data).hexdigest(). Remember to encode a string first, since hashlib takes bytes.
• Git: object ids are SHA-1 of a header plus the content, so the 40-character string in your log is not the SHA-1 of the file on disk.

The same file should produce the same value in all of these. When it does not, the two sides are usually hashing different things: one of them read a partial download, or the archive rather than its contents, or a text file whose line endings were rewritten in transit.

One browser caveat: crypto.subtle is only exposed in secure contexts, meaning HTTPS or localhost. This page is served over HTTPS so it works normally, but the same code copied onto a page opened over plain HTTP will find the API missing.

What you can safely paste here, and what a hash cannot do

Everything runs through crypto.subtle.digest(), the browser’s own implementation, so your input never leaves this tab. That holds for files too: reading and hashing both happen on your machine, and checksumming a 1 GB image generates no upload traffic at all.

• The file is read into the tab’s memory in one piece. A few hundred megabytes is comfortable; for a large disk image, the built-in commands above stream the file and will not make the tab struggle.
• A matching hash proves the content is unchanged, not that it is trustworthy. If an attacker controls the page publishing the checksum, they will publish the checksum of their own file. Guarding against that needs a signature, such as a signed release or a package manager verifying a key, rather than a checksum.
• SHA-1 is here for comparing against legacy values only. Do not pick it for a new signature, integrity check or identifier.
• Do not hash a password, key or personal record and treat the digest as a safe stand-in for the original. A digest of a predictable input is itself predictable, which is exactly why password storage needs a slow algorithm and a salt, as the first question below explains.