Hash generator — MD5, SHA-1 & SHA-256, offline

Hashing is the one operation where uploading is most obviously self-defeating. The usual reasons to hash something are to verify an download you do not fully trust, to fingerprint a file without exposing its contents, or to check a password or API key against a known digest. Sending that input to a stranger's server to compute the digest gives away the exact thing you were trying not to reveal — and for a large file it also means waiting on an upload to do arithmetic your own CPU can do instantly.

This generator runs entirely in your browser. SHA digests come from the WebCrypto API built into the browser itself, and MD5 from a small open-source library loaded with the page. There is no backend on this site to upload to, and a Content-Security-Policy blocks third-party requests — verify it with DevTools → Network, or by pulling your network connection and watching the hashes still compute.

Rather than making you pick an algorithm first, this tool computes all five digests simultaneously and fills the table as each finishes. That is the behaviour you want when you are checking a download against a published checksum, because projects are inconsistent about which algorithm they publish — you can just look for the row that matches instead of guessing and re-running.

• SHA-256 — the sensible default. It is what Git objects, TLS certificates, blockchain systems, and most release checksums use.
• SHA-384 and SHA-512 — wider digests from the same family. On 64-bit hardware SHA-512 is often faster than SHA-256 despite the longer output.
• SHA-1 — 160-bit, and broken for collision resistance since the 2017 SHAttered attack. Still needed for legacy interop and Git's object model.
• MD5 — thoroughly broken for security; collisions are generated in seconds. It survives purely as a fast non-adversarial checksum and for verifying old published hashes.

Output is lowercase hexadecimal by default, matching sha256sum, shasum, and certutil. Toggle UPPERCASE when you need to compare against a tool that prints digests the other way, so you are not eyeballing case differences by hand.

Choose Hash a file instead and pick any file to fingerprint it rather than typed text. The file is read into memory in the tab and hashed there — no upload, no size cap beyond available memory.

The standard use is confirming that a download arrived intact and unmodified: hash the file you received, compare against the checksum published on the project's site, and confirm the strings match end to end. It is worth being clear about what that does and does not prove. A matching checksum rules out corruption in transit and detects tampering by anyone who could not also edit the page publishing the checksum. If both come from the same compromised server, they will agree with each other — that is the gap cryptographic signatures exist to close.

Two identical files always produce identical digests regardless of filename, so hashing is also the reliable way to tell whether two copies of a document really differ. For text differences you want the diff checker instead.

A cryptographic hash is one-way and deterministic. There is no key and no way back — "decrypting" a SHA-256 digest is not a thing that exists. When a site claims to reverse a hash it is looking the digest up in a table of precomputed common inputs, which works precisely because the same input always yields the same output.

That determinism is why none of these five algorithms should be used to store passwords. They are built to be fast, and speed is exactly what an attacker with a leaked database wants. Password storage calls for a deliberately slow, salted algorithm — bcrypt, scrypt, or Argon2 — and that is a server-side concern, not something any browser-based tool should be doing for you. Use these hashes for integrity checks, fingerprinting, deduplication, and cache keys.

Also fully client-side: password generator for crypto-random passwords, UUID generator for random identifiers, and Base64 encoder for the same file as text.