Hash Generator

About Cryptographic Hash Generation

A cryptographic hash function takes an input of any size and returns a fixed-length string of bytes — the digest. The same input always produces the same digest, a one-character change produces a completely different one, and there is no practical way to run the function backwards to recover the input. Those three properties are what make hashes useful for verifying that data arrived intact, for comparing files without transmitting them, and for storing proof that something existed without storing the thing itself.

This generator uses the browser's built-in Web Crypto SubtleCrypto.digest() implementation — the same audited primitive the browser uses for TLS — and outputs the digest as lowercase hexadecimal, which is the format checksum files and most command-line tools use.

Supported Algorithms

• SHA-256 (256-bit, 64 hex characters) — the sensible default. Part of the SHA-2 family, no known practical attacks, and the algorithm behind TLS certificates, Git object addressing, Bitcoin, and virtually every published download checksum.
• SHA-512 (512-bit, 128 hex characters) — also SHA-2, with a larger digest and a wider internal state. Often faster than SHA-256 on 64-bit hardware. Use it when you want extra collision margin or you are matching an existing SHA-512 checksum.
• SHA-1 (160-bit, 40 hex characters) — cryptographically broken. A practical collision was demonstrated in 2017 (the SHAttered attack), and chosen-prefix collisions followed in 2020. It is here purely so you can verify legacy artifacts and Git commit IDs. Never use it for new signatures or integrity guarantees.

Why There Is No MD5 Option

MD5 is not offered because the Web Crypto API deliberately does not implement it — browsers refuse to ship a hash that has been trivially collidable since 2004, where two different files with the same digest can be produced in seconds on a laptop. If you need MD5 to check an old vendor checksum, use md5sum or certutil -hashfile <file> MD5 locally, and treat a match as "probably not corrupted in transit" rather than as any kind of security statement.

Common Use Cases

• Verifying a download. A project publishes the SHA-256 of its release; you hash what you received and compare. Matching digests mean the bytes are identical to what was published.
• Detecting changes. Hash a config file or a response body before and after a deployment. Equal digests prove nothing changed, no diff required.
• Deduplication and caching. Content-addressed storage, ETag values, and asset fingerprints in build tools all key on a digest of the content.
• Webhook signature debugging. Reproduce the digest a provider says it computed, so you can see whether your payload or your encoding is what differs.
• Learning and interview prep. See immediately how a single flipped character produces an entirely unrelated digest — the avalanche effect.

Hashing Is Not Encryption — and Not Password Storage

Two points that cause real security incidents. First, hashing is one-way: there is no "decode this hash" operation. Sites that appear to reverse a hash are looking it up in a precomputed table of common inputs, which is exactly why hashing a short, guessable string protects nothing.

Second, do not use a plain SHA-256 to store passwords. SHA-2 is designed to be fast, and fast is the wrong property here — commodity GPUs test billions of SHA-256 candidates per second, so an unsalted digest of a human-chosen password falls quickly. Password storage needs a slow, salted, memory-hard function: Argon2id, scrypt, or bcrypt. Use this tool for integrity checking and debugging, not as a credential store. If you need strong credentials in the first place, the Random Password Generator produces them from a cryptographic random source.

Privacy

Your input is encoded with TextEncoder and hashed by crypto.subtle.digest() inside the page. Nothing is sent over the network, logged, or stored — you can confirm it by opening your browser's network panel while you hash. That matters when the string you are hashing is a token, an internal identifier, or a customer record.