What is Hash Function?
Definition
A hash function is a one-way function that maps data of any length to a fixed-length value called a digest. The same input always produces the same digest, while the smallest change to the input produces a completely different one. For cryptographic hash functions such as SHA-256, recovering the input from the digest or finding two inputs with the same digest is infeasible, which is why they are used for integrity checks and digital signatures.
Also known as: hash, cryptographic hash function, message digest, digest function
A fingerprint for data
A hash function squeezes any input, however large, into an output of fixed size. For SHA-256 that is 256 bits, usually written as 64 hexadecimal characters. A five-letter word and a multi-gigabyte video produce digests of the same length. Changing a single character changes the entire result:
$ printf 'hello' | sha256sum
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
$ printf 'Hello' | sha256sum
185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969This avalanche effect is what lets a digest act as a fingerprint. If two files have the same SHA-256 digest, they are for all practical purposes identical; if the digests differ, at least one bit has changed.
What makes a hash “cryptographic”
NIST describes three properties that its approved hash functions must provide:
- Preimage resistance: given a digest, you cannot find an input that produces it. This is the “one-way” part.
- Second-preimage resistance: given one input, you cannot find a different input with the same digest.
- Collision resistance: you cannot find any two different inputs that share a digest.
The approved families today are SHA-2 (SHA-256, SHA-384, SHA-512 and others) and SHA-3. MD5 and SHA-1 have practical collision attacks and are retired for security purposes; NIST deprecated SHA-1 in 2011 and published a plan in 2022 to phase out its remaining limited uses. You will still find both in legacy systems, but they have no place in a new design.
Where hashes show up in web work
- Download integrity. The SHA-256 value next to a download lets you confirm the file arrived intact and unmodified.
- Subresource Integrity. When you load a script from a CDN with an
integrity="sha384-…"attribute, the browser hashes the file and refuses to run it if the digest does not match. SRI accepts SHA-256, SHA-384 and SHA-512. - Cache busting. Build tools put a content hash in file names (
app.3f9a1c.js), so a new build gets a new URL and long Cache-Control lifetimes become safe. ETags are often derived from a content hash as well. - Signatures and message authentication. Digital signatures sign a digest of the document rather than the document itself. HMAC combines a hash with a secret key to prove that a webhook or API request came from who it claims.
- Content addressing. Git identifies commits and files by the hash of their contents, so identical content always gets the same ID.
Not encryption, and not enough for passwords on its own
Hashing is often confused with encryption, but they solve different problems. Encrypted data can be decrypted with the key; a digest cannot be turned back into its input. There is no “decrypting a hash”: the only option is guessing inputs and comparing digests.
That guessing is exactly why a plain hash is wrong for passwords. SHA-256 is designed to be fast, and modern hardware computes billions of digests per second, so a leaked table of SHA-256 password hashes falls quickly. Passwords need purpose-built algorithms that are deliberately slow and salted, covered under password hashing. Likewise, non-cryptographic hashes such as CRC32 or xxHash, used in hash tables and checksums, are built for speed and must never be used for security.