Free SHA-256 Hash Generator

What a hash function actually does

A cryptographic hash takes input of any length and produces a fixed-length digest. Three properties make that useful. It is deterministic, so the same input always yields the same digest. It is one-way, so you cannot compute the input from the output. And it is avalanche-sensitive: flip a single bit of the input and roughly half the output bits change.

That last property is why hashes work as fingerprints. Change one byte in a 4 GB ISO and the SHA-256 digest is unrecognisably different, which is exactly what you want when verifying that a download arrived intact.

Which algorithm to pick

SHA-256 is the default answer. It is fast, universally supported, and has no known practical attacks. Reach for SHA-512 when you want a longer digest; on 64-bit hardware it is often faster than SHA-256 despite doing more work.

MD5 and SHA-1 are broken. Not theoretically, practically. MD5 collisions can be generated on a laptop in seconds, and SHA-1 fell to the SHAttered attack in 2017. Anyone who can choose the input can craft two different files with identical digests, which defeats every security use. They survive here for one legitimate reason: plenty of older projects still publish MD5 checksums, and verifying one is a non-adversarial check where collision resistance does not matter.

Worth noting that the Web Crypto API deliberately omits MD5, so the implementation on this page is hand-written. It is validated against the RFC 1321 test vectors.

Never hash a password with these

This is the most consequential mistake on the topic, so it deserves saying plainly. SHA-256 is the wrong tool for storing passwords, and it is wrong precisely because it is good at its job: it is fast. Modern hardware computes billions of SHA-256 digests per second, so an attacker holding your database can brute-force common passwords almost instantly.

Password hashing needs an algorithm designed to be slow and memory-hungry, with a unique salt per user so one precomputed table cannot attack every account at once. Use Argon2id where available, or bcrypt and scrypt, all of which handle salting for you. If you find yourself writingsha256(password), stop.

Doing it in code

// Browser — Web Crypto, async and hardware-accelerated
const bytes = new TextEncoder().encode("hello");
const buf = await crypto.subtle.digest("SHA-256", bytes);
const hex = [...new Uint8Array(buf)]
  .map((b) => b.toString(16).padStart(2, "0")).join("");

// Node
import { createHash } from "node:crypto";
createHash("sha256").update("hello").digest("hex");

// Shell
shasum -a 256 file.iso
sha256sum file.iso        # Linux

One gotcha in the browser: Web Crypto offers SHA-1, SHA-256, SHA-384, and SHA-512, but not MD5. If you need MD5 you must bring your own implementation. Another: always compare digests with a constant-time function when the comparison is security-relevant, since a naive string equality check leaks information through timing.

HMAC, in one paragraph

A plain hash proves data has not changed. It does not prove who produced it, because anyone can compute one. HMAC fixes that by mixing a secret key into the digest, so only a holder of the key can generate or verify it. This is how Stripe, GitHub, and most webhook providers sign their payloads: you recompute the HMAC with your shared secret and compare, which confirms both integrity and origin. Toggle HMAC above and supply a secret to see it.