Hash Generator

What hashing is, and why developers reach for it daily

A cryptographic hash function takes any input — a password, a file, a sentence — and produces a fixed-length string that uniquely represents it. The same input always produces the same hash. A trivial change (one bit) produces a completely different hash. And critically: you can't run the hash backwards to recover the original input. This combination makes hashes useful for verifying file integrity, checking whether two strings match without storing them in plain text, generating cache keys, deduplicating data, and powering blockchain proofs.

The five algorithms in this tool — and when to use each

MD5 (32 hex chars / 128 bits)

The oldest of the five, designed in 1991. Cryptographically broken. Multiple practical collisions are known — you can produce two different inputs with the same MD5 hash. Don't use MD5 for password storage, digital signatures, or any security-sensitive context. Still useful for: file checksums (where you trust the source isn't malicious), cache keys, deduplication, and matching against legacy systems that haven't been upgraded.

SHA-1 (40 hex chars / 160 bits)

Developed by NSA in 1995. Also broken. Google demonstrated a SHA-1 collision in 2017 (the "SHAttered" attack) costing about $110K in cloud compute. Modern security standards have removed SHA-1 — TLS certificates, code signing, and Git's hash format are all migrating away. Use SHA-1 only for legacy compatibility or non-security applications.

SHA-256 (64 hex chars / 256 bits)

Part of the SHA-2 family, published 2001. Currently considered secure. Used by Bitcoin, TLS, Git's new format, and most modern systems. Reasonable default choice for general-purpose hashing in 2024+.

SHA-384 / SHA-512 (96 / 128 hex chars)

Same family as SHA-256, with longer outputs. SHA-512 is sometimes faster on 64-bit hardware because it operates on 64-bit words natively. Use SHA-512 when you want extra collision resistance margin or when your hardware benefits from the wider operations. The security advantage over SHA-256 is largely theoretical.

Base64 encoding/decoding (not a hash)

Base64 isn't a hash — it's a reversible encoding that converts binary data to ASCII text. Used for embedding images in CSS, transmitting binary data over email, and compactly representing OAuth tokens. Anyone can decode Base64 back to the original; never use it for security.

Hashing for file integrity

The most common end-user hash use case: confirming a downloaded file wasn't corrupted in transit or tampered with. The standard workflow is:

1. Vendor publishes their software's official SHA-256 hash on their website (signed if possible).
2. You download the file, then compute its SHA-256 locally.
3. Compare your computed hash against the published hash. If they match, the file is intact.

This catches transit corruption (rare but possible) and CDN poisoning (less rare). It does NOT catch a sophisticated supply-chain attack where the attacker has compromised the vendor's website and replaced both the file AND the hash. For that, you'd need a signed hash (PGP) and a verified signing key obtained through a separate trusted channel.

Why you should NEVER use these hashes for password storage

This is the most common security mistake. MD5, SHA-1, SHA-256 — all of these are fast hashes designed to compute quickly. That's a feature for file integrity but a fatal weakness for password storage. A modern GPU can compute 10 billion SHA-256 hashes per second. If your database leaks, an attacker can crack 90%+ of common passwords in hours.

For password storage, use slow, memory-hard hash functions specifically designed to resist brute-force attacks:

• bcrypt — long-standing standard, configurable work factor.
• scrypt — bcrypt successor with memory hardness.
• Argon2 — modern winner of the Password Hashing Competition; preferred for new code.

These take 0.1-1 seconds to compute (compared to nanoseconds for SHA-256), which slows brute force by orders of magnitude while staying acceptable for legitimate logins.

How this tool works

SHA-1, SHA-256, SHA-384, and SHA-512 are computed via window.crypto.subtle.digest() — the browser's native Web Crypto API. This is the same code path that browsers use internally for TLS handshakes; it's fast, audited, and doesn't transmit your input anywhere. MD5 isn't in Web Crypto (intentionally — it's broken), so we include an inline RFC 1321 implementation that runs in your browser. Base64 uses the browser's built-in btoa() and atob().

All five hashes update live as you type. There's no submit button — every keystroke immediately recomputes all hashes. Even a 100KB input completes in milliseconds.

Practical workflows

API request signing. Many APIs (AWS, Stripe webhooks) require an HMAC-SHA256 signature on requests. Compute the signature locally, attach to the request header, the API verifies on receipt.

Cache invalidation. Hash a request URL + body to produce a unique cache key. When the inputs change, the hash changes, and you naturally invalidate.

Webhook verification. Verify a webhook came from the expected source by hashing the payload with a shared secret and comparing to the sent signature.

Deduplication. Hash uploaded files; if the hash already exists in your store, reuse the existing copy instead of duplicating.

Generating ETags. HTTP ETags are typically the SHA-256 of the response body, allowing efficient browser caching.

Privacy and security of this tool

Your input is hashed in your browser. Nothing is sent to any server. Even our server logs don't know what you hashed — there's no API call to our backend. This makes the tool safe for hashing sensitive data: passwords (for testing your hash function logic only — see warnings above), API tokens, internal document fingerprints. Once you close the tab, no trace remains.

FAQ

Why is MD5 still in this tool if it's broken? Many legacy systems still use MD5 (especially older databases and protocols). Until those systems are upgraded, you need to compute MD5 to interface with them.

Which is faster, SHA-256 or SHA-512? SHA-512 is often faster on 64-bit hardware because it processes 64-bit words natively while SHA-256 uses 32-bit words. On constrained hardware (microcontrollers), SHA-256 is faster.

Why do I get a different hash for what looks like the same input? Whitespace, line endings (Unix \n vs Windows \r\n), and invisible Unicode characters all change the hash. Use a hex viewer if you suspect hidden characters.

Can I hash a file? Currently the tool hashes text input only. For file hashing, see our file integrity checker tool.