keptlocal
Files never leave your browser

Hash Generator — MD5, SHA-1, SHA-256, SHA-512

Generate MD5 and SHA family hashes free in your browser — no signup, nothing uploaded. Type or paste text and get every common hash instantly, using the browser's native Web Crypto API for SHA and a compact MD5 implementation.

MD5
SHA-1
SHA-256
SHA-384
SHA-512
Hashes update as you type.

How to generate a hash

  1. Type or paste text into the box — every hash below updates automatically as you type.
  2. Click the copy icon next to any algorithm to copy that specific hash.
  3. Enable Uppercase if the system you're matching against expects uppercase hex (some legacy tools and Windows utilities do).

SHA-1, SHA-256, SHA-384, and SHA-512 run through crypto.subtle.digest() — the browser's native, standards-compliant implementation. MD5, which the Web Crypto API doesn't include (it's excluded deliberately, being cryptographically obsolete), runs through a small local JavaScript implementation instead. Both paths stay entirely in your browser.

What a hash function actually does

A hash function takes an input of any size and produces a fixed-length output — the "hash" or "digest" — such that the same input always produces the same output, and any change to the input, however small, produces a completely different output. Change one character anywhere in a 10,000-word document and its SHA-256 hash looks nothing like the original. That property is called the avalanche effect, and it's what makes hashes useful for verifying that two pieces of data are exactly identical without comparing them byte by byte.

Choosing an algorithm

  • MD5 (128-bit): Fast, universally supported, and still the default checksum format for many older download mirrors and legacy systems. Cryptographically broken — collisions (two different inputs producing the same hash) can be deliberately constructed — so never use it where an adversary might try to forge a match.
  • SHA-1 (160-bit): Was the web's default for years (Git still uses it internally for object IDs). Also broken for adversarial use since 2017, when researchers demonstrated a practical collision. Still fine for non-adversarial checksums.
  • SHA-256 (256-bit): Part of the SHA-2 family, no known practical collision attacks, and the current default for almost everything — TLS certificates, Bitcoin's proof-of-work, package manager checksums (npm, pip). Use this unless you have a specific reason not to.
  • SHA-384 / SHA-512 (384/512-bit): Larger SHA-2 variants. Marginal practical benefit over SHA-256 for most uses, but sometimes specified by systems that want extra headroom against future cryptanalysis.

What hashes are actually used for

File integrity verification. Software downloads are often published alongside a SHA-256 or MD5 checksum. After downloading, you hash the file yourself and compare it to the published value — a mismatch means the download was corrupted or tampered with. This is the single most common reason people reach for a hash generator.

Detecting duplicate or changed data. Instead of comparing two large files byte-by-byte, systems compare their hashes — if the hashes match, the files are (for all practical purposes) identical. Git uses this internally to detect whether file content has changed between commits.

Data structure lookups. Hash tables — the data structure behind most dictionaries, sets, and caches in every major programming language — use hash functions to map keys to storage locations in roughly constant time.

What hashes are not for: storing passwords. A general-purpose hash function like SHA-256 is fast — computable billions of times per second on commodity hardware — which is exactly the wrong property for password storage, since it makes brute-forcing a stolen password database cheap. Purpose-built password hashing functions (bcrypt, scrypt, Argon2) are deliberately slow and include built-in salting to prevent this.

Text hashing vs. file hashing

This tool hashes the text you type or paste. If you're verifying a downloaded file's checksum, be aware that hashing text copied from the file (or from a webpage describing it) is not the same as hashing the file's actual bytes — encoding differences, invisible characters, or line-ending conversions between operating systems can silently change the result. For verifying an actual file's integrity, use your operating system's built-in checksum utility (certutil -hashfile on Windows, shasum or md5 on macOS/Linux) against the file directly.

Privacy: what happens to your text

Nothing you type is transmitted anywhere — every algorithm runs locally, either through the browser's built-in Web Crypto API or a small local MD5 implementation. Open DevTools → Network while using the tool and you'll see no requests fire, which matters if you're hashing anything sensitive (an API secret, a password you're checking against a known-breach list) that you wouldn't want to send to a server.

Frequently asked questions

Is my text sent to a server to be hashed?
No. SHA-family hashes use the browser's native Web Crypto API; MD5 uses a small local JavaScript implementation. Both run entirely on your device — nothing is transmitted.
Why offer MD5 if it's considered broken?
MD5 and SHA-1 are cryptographically broken for security purposes (collisions can be deliberately engineered) but remain widely used for non-adversarial checksums — verifying a download completed correctly, checking file integrity, or matching values in legacy systems that still expect MD5. For anything security-sensitive (password storage, digital signatures), use SHA-256 or better.
Which hash should I use for password storage?
None of these, directly. Password storage requires a purpose-built algorithm with built-in salting and deliberate slowness — bcrypt, scrypt, or Argon2 — not a general-purpose hash function like SHA-256, which is fast by design and therefore vulnerable to brute-force attacks against stolen password databases.
Will the same input always produce the same hash?
Yes — every algorithm here is deterministic. The same exact input (including whitespace, capitalization, and line endings) always produces the same output hash, which is what makes hashes useful for verifying that two pieces of data are identical without comparing them directly.
Why do my hash and a file's published checksum not match?
Hashing is byte-exact — even one different character (extra trailing newline, different line-ending style, different text encoding) produces a completely different hash. If you're verifying a downloaded file, hash the file's raw bytes, not text you've copied and pasted from a webpage.