Hash Generator: MD5, SHA-1, SHA-256 and SHA-512 Checksums Online

A hash function takes an input of any size and returns a fixed-size output — a digest — derived entirely from that input. A cryptographic hash function adds three properties a generic checksum doesn't promise: it's deterministic(the same input always produces the exact same digest, on any machine, forever), it's one-way(recovering the input from the digest is computationally infeasible — there's no decrypt operation, because nothing was encrypted), and it exhibits the avalanche effect — flipping a single bit anywhere in the input changes roughly half the bits of the output. That last property is what makes a hash useful as a fingerprint: two inputs that differ by one character produce digests that look completely unrelated, so a hash either matches exactly or it tells you nothing in common at all.

SHA-256("The quick brown fox jumps over the lazy dog")
→ d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592

SHA-256("The quick brown fox jumps over the lazy dog.")
→ ef537f25c895bfa782526529a9b63d97aa631564d5d789c2b765448c8635fb6c

adding a single period rewrote roughly half the output bits

Hashing the same string with different algorithms shows what changes and what doesn't: the digest length is fixed per algorithm regardless of input size, and there's no relationship between the outputs of different algorithms on the same input.

SHA-1   (160-bit / 40 hex chars)
a9993e364706816aba3e25717850c26c9cd0d89

SHA-256 (256-bit / 64 hex chars)
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

SHA-512 (512-bit / 128 hex chars)
ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39
a2192992a274fc1a836ba3c23a3feebbd454d4423643ce80e2a9ac94fa54ca49f

The two things worth being direct about, because a lot of generic articles are vague on this: MD5 and SHA-1 are cryptographically broken for collision resistance — practical, demonstrated attacks exist for both, meaning an attacker can construct two different inputs that hash to the same digest. That makes them unsafe anywhere a hash needs to prove something to an adversary — digital signatures, TLS certificates, software supply-chain verification. It does not make them useless everywhere. For non-adversarial uses — deduplicating files, generating a cache key, a quick checksum where nobody is trying to forge a match — MD5 or SHA-1 is still fine, and often faster. SHA-256 is the reasonable default when you're not sure which to reach for; SHA-512 and SHA-384 exist for cases that want a larger security margin or perform better on 64-bit hardware.

The most common legitimate reason to hash something is file integrity verification: a publisher posts the SHA-256 of a release artifact next to the download link, and after downloading it you run it through a checksum calculator and compare the two hex strings. If they match exactly, the bytes you received are bit-for-bit identical to the bytes the publisher hashed — the download wasn't truncated by a flaky connection, corrupted by a bad mirror, or swapped for something else in transit. If even one bit differs anywhere in the file, the avalanche effect guarantees the digests look nothing alike, so there's no ambiguity about a “close enough” match — it either matches or it doesn't.

• Software downloads. Linux distributions, CLI tools, and installers routinely publish a SHA-256 alongside the file precisely so this check is possible.
• Deduplication. Hashing file contents and comparing digests finds byte-identical files without comparing every byte pairwise.
• Data integrity in storage or transit. Storing a hash alongside a record lets you detect later corruption by recomputing and comparing.

A plain hash proves the data wasn't altered — but it proves nothing about who produced it. Anyone can compute SHA-256(message), so if an attacker intercepts a message and replaces both the message and its published hash with their own, the check still passes. An HMAC (Hash-based Message Authentication Code) closes that gap by mixing a shared secret key into the computation, so a valid HMAC proves the sender knew the secret — not just that the bytes are unmodified.

payload = '{"event":"payment.succeeded","id":"evt_9f2a"}'

SHA-256(payload)
→ 7c9e6b2a1f4d8e0c3b5a7f9e1d3c5b7a9f1e3d5c7b9a1f3e5d7c9b1a3f5e7d9c
  anyone can compute this — proves nothing about origin

HMAC-SHA256(payload, key="whsec_shared_secret")
→ 4b7d1e9c3a5f7b9d1e3c5a7f9b1d3e5c7a9f1b3d5e7c9a1f3b5d7e9c1a3f5b7d
  only someone holding the key could produce this digest

This is exactly why webhook providers sign payloads with an HMAC generator rather than shipping a plain hash: the receiving server recomputes the HMAC of the raw request body using the shared webhook secret and compares it to the signature header. A match proves the request genuinely came from the provider and wasn't forged or replayed with tampered data — a bare SHA-256 could never establish that. It's the same mechanism JSON Web Tokens rely on when signed with HS256: the token's signature is an HMAC over the header and payload, and verifying it is covered in more depth in the JWT Decoder guide.

One boundary worth stating plainly: hashing — plain or HMAC — is never the right way to store passwords by itself, because it's deterministic and fast, exactly the properties that make brute-forcing a leaked password database practical. That job belongs to bcrypt, scrypt, or Argon2, which add salt and deliberate slowness by design.

GenKitLab's Hash Generator computes SHA-1, SHA-256, SHA-384, SHA-512 and HMAC digests of text or a file, in hex or Base64, entirely in your browser using the WebCrypto API — nothing you paste or upload is sent anywhere. That matters specifically for HMAC, where the input includes a secret key: a hash generator that runs the computation client-side means the secret never leaves your machine, which is not something you can say about every online tool claiming to do the same thing.