HomeDeveloper ToolsHash Generator

any text. instant hash.

generate MD5, SHA-1, SHA-256, and SHA-512 hashes for text or files. all hashes update in real-time as you type.

text input
MD5128-bit
hash will appear here
SHA-1160-bit
hash will appear here
SHA-256256-bit
hash will appear here
SHA-512512-bit
hash will appear here

What this tool does

Paste any text or upload any file, and get its cryptographic hash in MD5, SHA-1, SHA-256, or SHA-512. Hashing happens entirely in your browser via the WebCrypto API — your input never leaves the page.

What a hash is, and what it is for

A cryptographic hash is a fixed-size fingerprint of an input of any size. The same input always produces the same hash; any change to the input — even one bit — produces a completely different hash. The hash is one-way: you cannot reverse it back to the input.

Two everyday uses follow from those properties:

  • Verifying integrity. A download page publishes the SHA-256 of its installer. You hash the file you downloaded. If the hashes match, the file you got is byte-identical to the one published — no transmission corruption, no man-in-the-middle modification.
  • Identifying without revealing. A system stores the hash of a password rather than the password itself. When the user logs in, hash their input and compare. The system can verify the password without ever storing it. (In practice, password storage uses purpose-built functions like bcrypt or Argon2 rather than raw cryptographic hashes — see below.)

Hashing is not encryption

Encryption is reversible with a key. Hashing is not reversible at all. The single most common misunderstanding about cryptography is treating these as interchangeable.

If someone says “the password is encrypted,” ask whether they mean encrypted (where the plaintext can be recovered with the right key) or hashed (where it cannot be recovered, only verified by re-hashing the candidate). The answer determines what happens if the database leaks. An encrypted password column is recoverable by anyone who also gets the encryption key; a hashed password column is not directly recoverable, only attackable.

Which algorithm to pick

MD5 — broken, but still used

Designed in 1991. Produces a 128-bit hash. Deprecated for cryptographic purposes since the early 2000s, when efficient collision attacks were discovered — meaning two different inputs can be constructed that produce the same MD5 hash. Still used widely for non-security purposes: file integrity checks against accidental corruption, deduplication, hash tables. Do not use MD5 for password hashing, signatures, or any case where an attacker could control the input.

SHA-1 — also broken

160-bit output. Designed by the NSA, standardized in 1995. Practical collision attacks were demonstrated in 2017 (Google's SHAttered). Like MD5, still acceptable for non-adversarial integrity checks but not for anything security-relevant. Most systems have migrated off it.

SHA-256 — the modern default

Part of the SHA-2 family, designed in 2001. Produces a 256-bit hash. No practical collision or preimage attacks known. The right pick for any use case where you need a cryptographic-grade hash today: file integrity checks for security-sensitive downloads, content-addressable storage, digital signatures, blockchain identifiers, anywhere a hash is acting as an identifier or fingerprint.

SHA-512 — same family, more output

Also from the SHA-2 family. Produces a 512-bit hash. On 64-bit hardware, it is sometimes faster than SHA-256 because it processes 64-bit words natively. Use when you specifically need the longer output — usually because a downstream system requires it, not because SHA-256 was insufficient.

Why you should not hash passwords with these

SHA-256 is fast — that is a feature for integrity checks but a bug for password storage. An attacker with a leaked hash database can guess at billions of passwords per second on modern GPUs. Password hashing functions like bcrypt, scrypt, and Argon2 are deliberately slow and memory-hard to defeat this. If you are storing user passwords, use one of those. SHA-256 is for everything else.

How the WebCrypto API does this

Modern browsers expose hashing through crypto.subtle.digest(), which runs the actual hashing in native code (the same compiled primitives used by TLS in the browser). For a few-megabyte file, the operation completes in milliseconds. There is no meaningful performance reason to send the file to a server for hashing — the browser is faster than the round trip.

For very large files (multi-GB), the tool reads the input in chunks and feeds them through the hasher progressively, so the entire file does not need to fit in memory at once.

Common operations this is good for

  • Verifying a downloaded ISO against the publisher's posted SHA-256.
  • Generating a content fingerprint for caching layers (CDNs, browser cache busting, deduplication).
  • Checking that two files claimed to be identical actually are.
  • Producing a deterministic ID for a piece of content regardless of where it is stored.
  • Spot-checking that a file you uploaded somewhere arrived intact (hash both ends, compare).

The whole operation is one of those local-first computations with no good reason to involve a server — your file, your machine, your hash.

What this tool does

Paste any text or upload any file, and get its cryptographic hash in MD5, SHA-1, SHA-256, or SHA-512. Hashing happens entirely in your browser via the WebCrypto API — your input never leaves the page.

What a hash is, and what it is for

A cryptographic hash is a fixed-size fingerprint of an input of any size. The same input always produces the same hash; any change to the input — even one bit — produces a completely different hash. The hash is one-way: you cannot reverse it back to the input.

Two everyday uses follow from those properties:

  • Verifying integrity. A download page publishes the SHA-256 of its installer. You hash the file you downloaded. If the hashes match, the file you got is byte-identical to the one published — no transmission corruption, no man-in-the-middle modification.
  • Identifying without revealing. A system stores the hash of a password rather than the password itself. When the user logs in, hash their input and compare. The system can verify the password without ever storing it. (In practice, password storage uses purpose-built functions like bcrypt or Argon2 rather than raw cryptographic hashes — see below.)

Hashing is not encryption

Encryption is reversible with a key. Hashing is not reversible at all. The single most common misunderstanding about cryptography is treating these as interchangeable.

If someone says “the password is encrypted,” ask whether they mean encrypted (where the plaintext can be recovered with the right key) or hashed (where it cannot be recovered, only verified by re-hashing the candidate). The answer determines what happens if the database leaks. An encrypted password column is recoverable by anyone who also gets the encryption key; a hashed password column is not directly recoverable, only attackable.

Which algorithm to pick

MD5 — broken, but still used

Designed in 1991. Produces a 128-bit hash. Deprecated for cryptographic purposes since the early 2000s, when efficient collision attacks were discovered — meaning two different inputs can be constructed that produce the same MD5 hash. Still used widely for non-security purposes: file integrity checks against accidental corruption, deduplication, hash tables. Do not use MD5 for password hashing, signatures, or any case where an attacker could control the input.

SHA-1 — also broken

160-bit output. Designed by the NSA, standardized in 1995. Practical collision attacks were demonstrated in 2017 (Google's SHAttered). Like MD5, still acceptable for non-adversarial integrity checks but not for anything security-relevant. Most systems have migrated off it.

SHA-256 — the modern default

Part of the SHA-2 family, designed in 2001. Produces a 256-bit hash. No practical collision or preimage attacks known. The right pick for any use case where you need a cryptographic-grade hash today: file integrity checks for security-sensitive downloads, content-addressable storage, digital signatures, blockchain identifiers, anywhere a hash is acting as an identifier or fingerprint.

SHA-512 — same family, more output

Also from the SHA-2 family. Produces a 512-bit hash. On 64-bit hardware, it is sometimes faster than SHA-256 because it processes 64-bit words natively. Use when you specifically need the longer output — usually because a downstream system requires it, not because SHA-256 was insufficient.

Why you should not hash passwords with these

SHA-256 is fast — that is a feature for integrity checks but a bug for password storage. An attacker with a leaked hash database can guess at billions of passwords per second on modern GPUs. Password hashing functions like bcrypt, scrypt, and Argon2 are deliberately slow and memory-hard to defeat this. If you are storing user passwords, use one of those. SHA-256 is for everything else.

How the WebCrypto API does this

Modern browsers expose hashing through crypto.subtle.digest(), which runs the actual hashing in native code (the same compiled primitives used by TLS in the browser). For a few-megabyte file, the operation completes in milliseconds. There is no meaningful performance reason to send the file to a server for hashing — the browser is faster than the round trip.

For very large files (multi-GB), the tool reads the input in chunks and feeds them through the hasher progressively, so the entire file does not need to fit in memory at once.

Common operations this is good for

  • Verifying a downloaded ISO against the publisher's posted SHA-256.
  • Generating a content fingerprint for caching layers (CDNs, browser cache busting, deduplication).
  • Checking that two files claimed to be identical actually are.
  • Producing a deterministic ID for a piece of content regardless of where it is stored.
  • Spot-checking that a file you uploaded somewhere arrived intact (hash both ends, compare).

The whole operation is one of those local-first computations with no good reason to involve a server — your file, your machine, your hash.

more free tools

PDF utilities, image tools, developer helpers — all free, no signup.

Something wrong?