A hash generator with the SHA family in one pass.
Compute SHA-1, SHA-256, SHA-384, and SHA-512 of any text or file using the Web Crypto API — the same primitive your browser uses to verify TLS certificates. Live re-hash on every keystroke; nothing leaves your machine.
————MD5 is omitted by design — it has been cryptographically broken since 2004 (collisions findable in seconds), and the Web Crypto API does not implement it. Use SHA-256 for any new application.
Hashing happens in this browser tab via `crypto.subtle.digest`. Files are read locally with `FileReader`; the bytes never leave the page. We never see your input, and the page makes no network calls related to it.
The whole SHA family, live, with both encodings.
Four hash algorithms computed in parallel on every change, in either hex or base64, with file mode for verifying download integrity. Built on Web Crypto so the implementation is whatever your browser already trusts for TLS.
All four algorithms hash the input simultaneously and render side by side. Easy to compare digests across systems that picked different defaults — checksums, container layers, signature payloads.
Hashing runs through `crypto.subtle.digest`, the same primitive the browser uses for TLS. JS-pure SHA implementations (still common in npm) are 5–50× slower and unaudited; the native one is FIPS 140-2 grade.
Toggle between lowercase hex (the standard for `sha256sum` and most Linux tools) and base64 (used in HTTP `Sec-Fetch-Integrity`, S3 ETags, container content digests). Same digest, different encoding.
Drop a file (up to 50 MB) to verify download integrity against a published checksum. The file reads via `FileReader`; bytes are passed to `digest` directly without being copied through a string.
Every keystroke triggers a fresh hash on every algorithm. No Hash button blocking your flow — and no spinner, because Web Crypto digests at GB/s.
Text input is converted to UTF-8 bytes via `TextEncoder` before hashing — so the digest matches what `sha256sum` of a UTF-8 file containing the same string would produce, character by character.
Click any algorithm row to copy that one digest. The button flashes to confirm — no clipboard guessing.
Use anonymously, on as many inputs as you want. No account, no history, no telemetry. Inspect the network tab — there is nothing outbound to inspect.
Wherever a digest has to match.
Most release pages publish a SHA-256 next to the file. Drop the downloaded file in here, compare digests — if they match, the bytes are intact and unaltered.
Git uses SHA-1 (and now SHA-256 in newer repos). Useful when debugging an object reference: paste the file contents, get the same hash Git would compute.
Hashing the request input gives you a stable, fixed-length cache key independent of the input shape. SHA-256 is overkill for security but perfect for collision avoidance.
Webhooks (Stripe, GitHub, Slack) sign payloads with HMAC-SHA-256. To verify locally, hash the canonical body string here and compare with the header — confirms what the signing routine on the server should produce.
IPFS, OCI image layers, and Nix store paths are all keyed by SHA-256 of content. Hash a file here to predict the storage path before uploading.
When verifying SSH keys or TLS certificates by fingerprint, paste the public key bytes and compare the SHA-256 here against the expected value before trusting the connection.
Hashing, the plain answers.
MD5 has been cryptographically broken for ~20 years — practical collision attacks were demonstrated in 2004, and chosen-prefix collisions in 2008. Anything that depends on MD5 for security (signatures, integrity, deduplication-with-trust) is vulnerable. The Web Crypto API does not implement it. Use SHA-256 for any new application; if you are stuck verifying a legacy MD5 checksum, use a command-line tool like `md5sum`.
The Web Crypto API only implements the four SHA variants. Anything else requires a JS reimplementation — slower, unaudited, larger bundle. We chose to surface only what the browser natively supports; if you need an exotic hash, reach for a CLI tool or a server.
Not for anything security-sensitive. SHA-1 collisions have been demonstrated (Google's SHAttered attack, 2017). It is included here for compatibility with legacy systems — Git object hashes, old TLS certificates, some checksum files. For new applications use SHA-256.
Both are from the SHA-2 family; SHA-512 has a larger internal state and 64-bit operations (vs SHA-256's 32-bit). On 64-bit hardware, SHA-512 can actually be faster than SHA-256, and the longer output reduces collision probability further. For most uses they are interchangeable; pick SHA-256 unless you have a specific reason to prefer 512.
No. Hashing runs entirely in this browser tab via `crypto.subtle.digest`. Files are read locally with `FileReader`. The page makes no network calls. Open DevTools → Network and watch nothing happen as you paste or drop a file.
Files up to 50 MB are accepted. Web Crypto can technically hash much larger inputs, but past 50 MB the browser starts using noticeable memory to hold the file, and the file pipe becomes the bottleneck. For multi-GB files use a CLI tool — `sha256sum` is faster and streaming.
Building services where every byte has to match?
Sign up for the free tier and you get $100 in credits, plus VMs, managed databases, object storage with content-addressed keys, and zero-config autoscaling across four regions.