Hash Generator

A cryptographic hash function takes any input — a single byte or a multi-gigabyte file — and produces a fixed-length output called a digest. SHA-256 always returns 256 bits regardless of input size. The function is deterministic (same input always produces the same digest) one-way (you cannot recover the input from the digest) and collision-resistant (it is computationally infeasible to find two inputs that produce the same digest). Hashes show up everywhere in modern systems: file integrity verification (download a Linux ISO compare the SHA-256 against the project's published checksum to confirm the bytes were not corrupted or tampered with in transit) content addressing (Git stores every blob and tree by SHA-1; IPFS uses multihash; Docker layer IDs are SHA-256) proof-of-work (Bitcoin's proof-of-work hashes block headers with double SHA-256 until the digest starts with enough leading zeroes) webhook signature verification (Stripe GitHub Slack all HMAC-sign their webhook payloads so receivers can verify authenticity) JWT signing (HS256 algorithm = HMAC-SHA-256) AWS Signature v4 request signing password storage (with a slow function like bcrypt or argon2 — never SHA-256 directly) and content-addressable cache keys. This tool ships every hash algorithm anyone actually needs in a browser tool: MD5 SHA-1 SHA-256 SHA-384 and SHA-512 plus HMAC variants of all of them. Inputs can be plain text pasted strings or any file under 50 MB. Output is shown in both hex and base64 simultaneously since different ecosystems prefer different representations — Linux command-line tools and certificate fingerprints use hex JWT signatures and base64-encoded API responses use base64. Computation is fully local: text never leaves the browser; file bytes never leave the browser. SHA-* algorithms run through the native Web Crypto API which compiles to OS-level SHA-NI hardware instructions on every modern CPU.

MD5 (1992 128 bits) is broken for collision resistance — researchers have generated arbitrary collisions in seconds since 2008 — but is still useful for non-adversarial integrity checking. File ETags content-addressable cache keys error-detection on un-trusted-but-not-actively-hostile channels (a corrupted download a memory bit flip) the v3 UUID spec and a lot of legacy interop all happily use MD5. The 128-bit output is roughly half the size of SHA-256 in storage which matters for systems that store millions of digests. Just never use it where an attacker might intentionally manipulate inputs. SHA-1 (1995 160 bits) is also collision-broken (the 2017 SHAttered attack produced two PDFs with identical SHA-1) but the practical exploit window is narrower than MD5 — finding a collision still costs hundreds of GPU-hours. SHA-1 is fine for non-security checksums (still used by Git by older SSH host keys by PGP/GPG) but should never be picked for new security-sensitive code. SHA-256 SHA-384 and SHA-512 are the SHA-2 family. None has any known practical attack against collision or preimage resistance. SHA-256 is the default — it is fast (CPUs have dedicated SHA-NI instructions) the output is 256 bits which is comfortable margin against any collision attack and every modern API and library expects it. SHA-384 is SHA-512 truncated to 384 bits and exists primarily for matching specific government compliance regimes (NSA Suite B specified it). SHA-512 is useful when you need the larger output for HKDF expansion very long-lived archival checksums or signature schemes that demand it. There is no security reason to pick SHA-512 over SHA-256 for ordinary use but on 64-bit hardware the per-byte cost is similar and the larger output is essentially free.

A plain hash digest authenticates nothing — anyone can compute SHA-256 of any input. The digest only proves that whoever produced it had access to the input bytes which is meaningless when the input is public. HMAC fixes this by combining the input with a secret key in a way that produces an output the verifier can re-compute only if they share the key. RFC 2104 specifies the construction: pad the key to the hash function's block size XOR with two constants (ipad = 0x36 opad = 0x5C) and run two passes of the hash function — outer over (opad-XOR-key || hash(inner-XOR-key || message)). The math guarantees that without the key you cannot forge a valid HMAC tag for any chosen message even with full knowledge of the algorithm and large samples of (message tag) pairs. HMAC is the workhorse of authenticated communication on the web. JWT's HS256 algorithm is HMAC-SHA-256 — the issuer signs the payload the verifier re-signs it with the same secret and checks the tags match. AWS Signature v4 derives a signing key with five layers of HMAC-SHA-256 from your secret access key. Stripe GitHub Shopify Slack Twilio and most other webhook senders compute HMAC-SHA-256 over the raw request body send it in an X-*-Signature header and the recipient must re-compute and constant-time-compare. TOTP (the 6-digit codes from Google Authenticator) is HMAC-SHA-1 of a 30-second time counter. The HMAC mode in this tool computes the same value for any of the supported hash algorithms so you can verify webhook signatures debug JWT signing or test AWS-style signing flows without writing scratch code.

For new code: SHA-256. It is the modern default — fast in software fast in hardware (every modern CPU has SHA-NI instructions) 256 bits of output that is more than enough for any non-quantum collision-resistance need and supported in every standard library and browser. Reach for SHA-512 only if you specifically need 512-bit output (HKDF expansion very long-lived archive checksums signature schemes that demand it). Reach for SHA-384 only if you are matching an existing API. Use MD5 and SHA-1 only for non-security checksums (file integrity ETags content addressing) — they are both broken for collision resistance but they are still fine for detecting accidental corruption.

Browser Web Crypto (SubtleCrypto) deliberately omits MD5 to discourage new uses — the algorithm has been broken for collision resistance since 2004 and is unsuitable for security-sensitive workloads. This generator hand-rolls MD5 in pure JavaScript per RFC 1321 because non-security uses (file ETags content-addressable cache keys the v3 UUID spec legacy interop) are still common. SHA-1 SHA-256 SHA-384 and SHA-512 all go through Web Crypto's native implementation which is significantly faster than any JavaScript hash for inputs over a few hundred KB.

HMAC (Hash-based Message Authentication Code RFC 2104) is a construction that combines a hash function with a secret key to produce an authentication tag. The recipient who shares the same key can re-compute the tag and verify that the message was both produced by someone with the key and not modified in transit. HMAC is the building block under JWT signatures (HS256 = HMAC-SHA256) AWS Signature v4 webhook signature verification (Stripe GitHub Slack all sign payloads with HMAC) TOTP codes OAuth 1.0a and many cookie-signing schemes. Plain hashes do not authenticate — anyone can compute SHA-256 of anything. HMAC is what binds the digest to a secret.

No. Hashes are one-way functions — you can go from input to digest but you cannot recover the input from the digest. There is no key no decryption operation no reverse pass. Encryption is two-way: with the key ciphertext converts back to plaintext. Hashes are used for fingerprinting (does my file match the published checksum?) integrity (did this data change in transit?) authentication-with-secret (HMAC) proof-of-work (Bitcoin) and content addressing (Git IPFS). They are not used for confidentiality. Hashing a password sounds like encryption but is actually one-way — that is exactly the point: even if the database leaks the attacker cannot turn the hash back into the password without an offline guessing attack (which is why passwords need slow hashes like bcrypt or argon2 not fast hashes like SHA-256).

An MD5 collision. Researchers have constructed pairs of inputs with identical MD5 digests since 2004; today you can generate one in under a minute on a laptop. SHA-1 has had practical collisions since the SHAttered attack in 2017. Neither algorithm should be used to protect against an adversary who can choose inputs. SHA-256 and SHA-512 have no known practical collisions. For accidental corruption (random bit-flips on disk network errors) even MD5 is essentially perfect — collisions only matter when an attacker is actively trying to produce them.

MD5 = 128 bits (32 hex chars). SHA-1 = 160 bits (40 hex chars). SHA-256 = 256 bits (64 hex chars). SHA-384 = 384 bits (96 hex chars). SHA-512 = 512 bits (128 hex chars). Base64 representations are 4/3 the byte length: MD5 = 24 chars (with padding) or 22 (without) SHA-256 = 44 chars or 43 SHA-512 = 88 chars or 86. Use base64 when storage matters (databases URLs headers); use hex when human readability matters (terminal output error messages file checksums published alongside downloads).

Compare mode hashes two inputs in parallel and shows whether each algorithm agrees. The use case is integrity verification without trusting either side: paste the file contents you downloaded into A paste a published checksum into B's expected text source and check whether SHA-256 matches. Or paste two strings that look identical (with hidden whitespace invisible Unicode characters or trailing newlines) and let SHA-256 tell you whether they actually are. The comparison is byte-level not character-level — perfect for catching encoding mismatches.