Hash Generator (SHA-256, SHA-512, MD5)

Every hash function maps input to a fixed-size output. A cryptographic one adds three guarantees: it is infeasible to find an input for a given hash (preimage resistance), to find a second input with the same hash as a known one, or to find any two inputs that collide. Two properties are visible right away:

• Deterministic and fixed length. The same bytes always give the same digest. SHA-256 is always 256 bits (64 hex characters), whether you hash one byte or a 4 GB disk image.
• Avalanche effect. Changing a single bit of the input flips about half of the output bits, so similar inputs give unrelated-looking hashes:

SHA-256("hello world")  = b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9
SHA-256("hello world!") = 7509e5bda0c762d2bac7f90d758b5b2263fa01ccbc542ab5e3df163be08e6ca9

The flip side is that invisible differences matter. The most common "wrong hash" report is a trailing newline: echo hello | sha256sum hashes hello\n, not hello. Use printf '%s' hello or echo -n. Windows line endings (\r\n), a byte-order mark, or a different text encoding change the hash in the same way. The byte count next to the input tells you exactly how many bytes were hashed.

Projects publish a checksum next to their installers and ISO images. Hash the file you downloaded and compare the result. You can drop the file into this page and paste the published value into the compare box, or use the built-in command on your OS:

# macOS
shasum -a 256 ubuntu-24.04-desktop-amd64.iso

# Linux (and check a whole SHA256SUMS file at once)
sha256sum ubuntu-24.04-desktop-amd64.iso
sha256sum -c SHA256SUMS --ignore-missing

# Windows PowerShell
Get-FileHash .\ubuntu-24.04-desktop-amd64.iso -Algorithm SHA256

# Windows cmd
certutil -hashfile ubuntu-24.04-desktop-amd64.iso SHA256

The compare box accepts all of these output formats. It ignores case and surrounding spaces, strips a trailing file name or a sha256: prefix, and also accepts certutil's space-separated hex. A matching checksum proves that the file is the one the checksum describes. It only proves the file is authentic if the checksum came from a trusted source, such as an HTTPS page or a GPG-signed SHA256SUMS file, rather than the same mirror that served the download.

SHA-256 is designed to be fast, and that is exactly what you don't want for passwords. An attacker who steals a table of sha256(password) values can test billions of guesses per second on a GPU, and an unsalted table falls to precomputed lookups. Adding a salt stops the lookups but not the speed.

Use a dedicated password hashing function instead: Argon2id (the current OWASP recommendation), scrypt or bcrypt. They generate a unique salt for each password and are deliberately slow. Argon2 and scrypt are also memory-hard, which makes GPU and ASIC cracking expensive. Their cost settings let you raise the work factor as hardware gets faster.

A plain hash proves integrity only if the attacker can't replace the hash too. An HMAC mixes a secret key into the computation (RFC 2104), so only someone who holds the key can produce a valid tag. Webhooks from payment providers and Git hosts are signed this way. The receiver recomputes the HMAC over the raw request body and compares it in constant time:

const crypto = require('crypto');
const expected = crypto.createHmac('sha256', process.env.WEBHOOK_SECRET)
    .update(rawBody)            // the exact bytes received, not re-serialized JSON
    .digest('hex');
const ok = crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(signatureHeader));

Don't build your own sha256(secret + message). SHA-256 and SHA-512 are vulnerable to length-extension attacks, which let an attacker append data and compute a valid hash without knowing the secret. HMAC's nested construction prevents that. The HS256 algorithm in a JSON Web Token is HMAC-SHA-256 as well, which you can see in the header with the JWT decoder. If you need to send raw digest bytes in a header, switch the output to Base64 or use the Base64 encoder.