Hashing explained: digests, checksums, and integrity

A cryptographic hash function turns any input into a fixed-length digest. The same input always produces the same digest, a single changed byte produces a completely different one, and there is no practical way to run the function backwards. Those three properties are why digests appear everywhere integrity matters: file downloads, cache keys, deduplication, and signature schemes.

What a digest does and does not prove

A matching digest proves two inputs are byte-identical. It says nothing about who produced them. Anyone can recompute a public SHA-256 value for modified content, which is exactly why webhook providers sign payloads with a keyed construction instead of publishing a plain checksum.

Choosing an algorithm

For general integrity work, SHA-256 is the interoperable default and SHA-512 offers a larger margin and often better throughput on 64-bit hardware. MD5 and SHA-1 are broken for collision resistance and should not be used for anything security-relevant, even though they still appear in legacy checksums.

Passwords are a different problem

Fast hashes are the wrong tool for stored credentials precisely because they are fast: an attacker with a leaked table can try billions of guesses. Password storage needs a deliberately slow, salted algorithm such as Argon2 or bcrypt, with a work factor tuned to your hardware.

Practise locally

Compute digests for text or files with Hash Generator, sign a payload with HMAC Generator, and compare the two workflows side by side in HMAC vs Plain Hash. For password-specific guidance, continue with password security basics.