Free Hash Generator

Type or paste any text below and click Generate Hashes to compute its MD5, SHA-1, SHA-256, and SHA-512 digests as hex strings. Everything runs in your browser — nothing you type is uploaded or stored.

About this Hash Generator

A cryptographic hash function takes an input of any length and produces a fixed-size fingerprint called a digest. Change a single character in the input and the digest changes completely — a property called the avalanche effect. That makes hashes ideal for verifying file downloads, detecting accidental corruption, generating cache keys, deduplicating data, and (with the right algorithms) securing passwords and signatures. This free Hash Generator computes the four digests developers reach for most — MD5, SHA-1, SHA-256, and SHA-512 — side by side, so you can compare, copy, and paste whichever format the task requires.

Everything happens locally in your browser. MD5 is computed by a small JavaScript implementation of RFC 1321, while SHA-1, SHA-256, and SHA-512 use the browser's built-in Web Crypto API (crypto.subtle.digest), the same primitives that power TLS in your browser. There is no API call, no upload, and no storage — the text in the box never leaves your machine. Input is encoded as UTF-8 before hashing, which is the convention used by virtually every command-line tool and library, so the results here match what you would get from sha256sum, Python's hashlib, or Node.js's crypto module for the same text.

Hashing is one-way

Unlike encoding (reversible by design) and encryption (reversible with the key), hashing has no inverse. A digest is a deterministic summary, not a container: given only 5eb63bbbe01eeed093cb22bb8f5acdc3, there is no computation that yields "hello world" back. The only way to "reverse" a hash is to guess candidate inputs, hash each one, and compare — which is exactly what brute-force and rainbow-table attacks do. This is why hashing short, predictable inputs (like plain passwords) provides far less protection than the math suggests: the attacker does not break the hash, they simply guess the input.

Which algorithm should you use?

• MD5 (128-bit) — cryptographically broken. Practical collision attacks have existed since 2004, meaning attackers can construct two different inputs with the same MD5 digest. Never use it for signatures, certificates, or passwords. It remains fine for non-adversarial jobs: quick checksums, cache keys, ETags, and detecting accidental corruption.
• SHA-1 (160-bit) — also broken for security. Google demonstrated a practical collision ("SHAttered") in 2017, and browsers and CAs have long rejected SHA-1 certificates. Like MD5, it is acceptable only for legacy compatibility and non-security checksums (Git historically used it for object IDs, paired with collision detection).
• SHA-256 (256-bit) — the current general-purpose default. Part of the SHA-2 family, with no practical attacks known. Use it for integrity verification, digital signatures, HMACs, and content addressing.
• SHA-512 (512-bit) — SHA-2 with a larger digest and 64-bit internal operations, which often makes it faster than SHA-256 on 64-bit CPUs. Choose it when you want a bigger security margin or your protocol specifies it.

Never store passwords as plain hashes

A common and dangerous mistake is storing user passwords as MD5 or SHA-256 digests. Fast hashes are designed to be fast — modern GPUs compute billions of SHA-256 hashes per second, so an unsalted fast hash of a typical password falls in seconds to dictionary attacks. Password storage needs the opposite: algorithms that are deliberately slow and memory-hard, with a unique salt per user. Use bcrypt, scrypt, or Argon2 (the current recommendation from the Password Hashing Competition). If you are generating passwords rather than storing them, our Password Generator creates strong random ones locally.

Common uses for this tool

• Verify a download — hash the file's published test string or compare a vendor's published SHA-256 against your local sha256sum output, using this tool to sanity-check small text fixtures.
• Debug HMAC/signature code — confirm your code's intermediate digest for a known input matches the expected value before adding keys into the mix.
• Generate deterministic IDs — hash a canonical string (like a URL or a normalized JSON document) to get a stable identifier or cache key.
• Compare environments — hash configuration text on two machines to check whether the contents are byte-identical without eyeballing diffs.

One caveat when comparing results across tools: whitespace counts. A trailing newline (which echo adds by default on the command line — use echo -n to suppress it) produces a completely different digest. If your hashes do not match another tool's, check for invisible characters first.

FAQ: Hash Generator