Hash functions explained: SHA-256, checksums and password hashing

Updated: 14 October 2026

A hash function turns any input — a word, a password, a 4 GB file — into a short fingerprint of fixed length. The same input always gives the same fingerprint, and the smallest change gives a completely different one. That makes hashes the standard way to check that a file arrived intact, to store passwords without keeping the passwords themselves, and to sign messages. This guide explains what makes a hash secure, which algorithms are still safe, how to check a download, and why the fast hash that is right for a file is the wrong one for a password.

What a hash function does

A hash function reads data of any length and returns a digest of fixed length. SHA-256, the most common today, always returns 256 bits, written as 64 hexadecimal characters, whether the input is one letter or a whole disk image.

c3c211099e2db0d1bb97343886c2b7e23981b636107a296a9fe642b99ca4cc1bSHA-256 of nTools.
420849368aee5e9b6838f98b4dde3f493de84c420baa785ea58a08acc2c0cfafSHA-256 of ntools: one letter changed to lower case, an unrelated digest.

Every hash function is deterministic — the same input gives the same digest on any computer — and quick to compute. A cryptographic hash adds the guarantees in the next section, which are what make it usable for security.

A digest is not a compressed copy: 64 characters cannot hold a 4 GB file. In theory many inputs share each digest; a secure hash just makes them infeasible to find in practice.

Open the hash generator

What makes a hash secure

The US standard that defines SHA-256, FIPS 180-4, describes the algorithms as secure because certain searches are computationally infeasible. In practice there are three properties:

Preimage resistance: given a digest, nobody can find an input that produces it. This is what “one-way” means.
Second-preimage resistance: given a file, nobody can make a different file with the same digest.
Collision resistance: nobody can find any two different inputs with the same digest, even choosing both freely.

Collision resistance is the first to fall, because the attacker controls both inputs. That is what happened to MD5 and SHA-1. It matters because digital signatures and certificates are computed over a hash of the document: two documents with the same hash share the same signature.

MD5, SHA-1, SHA-2 and SHA-3

Algorithm	Digest	Status
`MD5`	128 bits, 32 hex characters	Broken: collisions are practical. RFC 6151 (2011) rules it out wherever collision resistance is required, such as digital signatures.
`SHA-1`	160 bits, 40 hex characters	Broken: first public collision in 2017. NIST says it should be phased out by 31 December 2030.
`SHA-256`	256 bits, 64 hex characters	Secure. Part of the SHA-2 family (FIPS 180-4) and the usual default today.
`SHA-384, SHA-512`	384 and 512 bits, 96 and 128 hex characters	Secure. Also SHA-2, with a longer digest.
`SHA-3`	224 to 512 bits, depending on the variant	Secure. Standardised in 2015 (FIPS 202) on a different design, Keccak, to supplement SHA-2, not to replace it.

The SHA-1 collision, called SHAttered, was announced by Google and CWI Amsterdam on 23 February 2017: two different PDF files with the same SHA-1 digest, found with about 9.2 quintillion SHA-1 computations. Since then MD5 and SHA-1, as plain hashes, survive only as quick checks against accidental damage. Microsoft's documentation for the Windows file-hash command says the same: use them only for simple change validation, never for files that must be protected from tampering.

The nTools hash generator offers SHA-256, SHA-384 and SHA-512. It uses the browser's built-in Web Crypto API, which also supports SHA-1 — with a warning not to use it for cryptography — and does not offer MD5 at all.

Checking a download

Software publishers often list a checksum next to the file, usually SHA-256. After downloading, you compute the digest of your copy and compare.

Note which algorithm the publisher used and copy the published checksum.
Compute the digest of the downloaded file with the same algorithm: in the nTools hash generator for files up to 200 MB, or with a command such as the ones below for any size.
Compare every character, not just the first and last few. Upper and lower case do not matter in hexadecimal.

Get-FileHash .\file.isoWindows PowerShell. SHA-256 unless you add -Algorithm.
sha256sum file.isoLinux.
shasum -a 256 file.isomacOS.

A match proves the file is the one that was hashed; it does not prove who hashed it. An attacker who can replace the file on a site can usually replace the checksum on the same page too. That is why projects such as Ubuntu also sign their list of checksums: you first verify the signature with GPG, then the file against the list. Once the signing key's fingerprint has been checked against the project's own site, the result holds even if you downloaded from an untrusted mirror.

Hashing, encryption and encoding

Method	Reversible?	Key?	Used for
Hashing (e.g. SHA-256)	No	No	Checking integrity, identifying data, storing passwords with a slow algorithm
Encryption (e.g. AES)	Yes, with the key	Yes	Keeping data secret
Encoding (e.g. Base64)	Yes, by anyone	No	Carrying binary data as text, in e-mail, URLs and JSON

Base64 and URL encoding protect nothing: they change how data is written, not who can read it. Encrypted passwords are also worse than hashed ones, OWASP warns: encryption is two-way, so anyone who can decrypt gets the original passwords back. It is only for the rare case where the original must be recovered.

Why a fast hash is wrong for passwords

A site should never store your password, only a hash of it: at login it hashes what you type and compares the result. The catch is speed. A hash that checks a 4 GB download in seconds lets anyone who steals the database test billions of guesses a second.

Algorithm	Guesses per second, one RTX 4090	Time to try every 8-character password of lowercase letters and digits
MD5	164 billion	17 seconds
SHA-1	51 billion	56 seconds
SHA-256	22 billion	2 minutes
SHA-512	7.5 billion	6 minutes
PBKDF2-HMAC-SHA256, 600,000 iterations	about 15,000	about 6 years
bcrypt, cost 10	about 5,750	about 15 years

Speeds from the hashcat 6.2.6 benchmark on one NVIDIA RTX 4090 graphics card. The last two rows are scaled from the benchmark's own settings (999 PBKDF2 iterations, bcrypt cost 5), because the time grows in proportion to the work. The search covers all 36⁸, about 2.8 trillion, candidates. Real attacks are faster still: they use many cards at once and try likely passwords first.

Salt: the same password, a different hash

Without salt, everyone whose password is 123456 has the same stored hash, and attackers keep tables of the hashes of millions of common passwords, so finding them is a lookup, not a search.

8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92SHA-256 of 123456, unsalted: the same in every database that stores it this way.

A salt is a random value created for each password, stored next to its hash and mixed into it. It is not secret. Its job is to make every stored hash unique, so precomputed tables are useless and each account has to be attacked on its own.

NIST SP 800-63B-4 requires passwords to be salted and hashed with a suitable password-hashing scheme and a salt of at least 32 bits, and recommends a cost factor as high as practical. It also recommends an extra keyed step with a secret key stored apart from the hashes, ideally in a hardware security module. OWASP calls that secret a pepper.

What to use instead

Password-hashing functions are slow on purpose, take the salt as an input and have a cost setting that should rise as hardware gets faster. The OWASP Password Storage Cheat Sheet gives these minimums:

Algorithm	Minimum settings	When
`Argon2id`	19 MiB of memory, 2 iterations, parallelism 1	First choice. Each guess needs memory, which blunts the advantage of graphics cards. Specified in RFC 9106 (2021).
`scrypt`	N = 2¹⁷, r = 8, p = 1	When Argon2id is not available. Also needs memory.
`bcrypt`	Cost 10 or more	Older systems. Most implementations accept at most 72 bytes of password; longer ones are cut or rejected.
`PBKDF2-HMAC-SHA256`	600,000 iterations	When FIPS-140 compliance is required.

These are minimums, meant to keep one login to a fraction of a second on the server while making each guess expensive. You cannot see which one a site uses, which is why the advice in the password guide — long, random and never reused — assumes the worst case.

HMAC: a hash with a key

A plain hash shows that data has not changed, but anyone can compute it: whoever alters the data can simply recompute the hash. HMAC, defined in RFC 2104 in 1997, mixes a secret key into the hash, so only someone with the key can produce or check the result.

That is how APIs sign requests, how webhooks prove they came from the sender, and how many JSON Web Tokens are signed: the JWT algorithm HS256 is HMAC with SHA-256.

Frequently asked questions

Can a hash be reversed?

No. The digest does not contain the input, so there is nothing to decode. What attackers do is guess: they hash candidates until one matches. That works for short or common inputs such as passwords and fails for long random ones.

Is MD5 still fine for anything?

For spotting accidental changes, such as a corrupted copy or a duplicate file, yes. Not where someone might tamper on purpose, and never for passwords or signatures.

Can two files have the same SHA-256 digest?

In theory, yes: there are more possible files than digests. In practice no collision has ever been found for full SHA-256, and a brute-force search would take around 2¹²⁸ attempts.

Is a longer digest always more secure?

Only up to a point. 256 bits already puts a collision search far out of reach; the soundness of the algorithm matters more, as SHA-1 showed. SHA-384 and SHA-512 are used where a rule requires them or for extra margin.

Is my file uploaded when I hash it on nTools?

No. The file is read and hashed in your browser, and only the digest is shown.

Previous in the series ← Password strength explained: length, entropy and passphrases