Skip to content
Advertisement

Hash Generator

Compute MD5, SHA-1, SHA-256, and SHA-512 digests, or Argon2 password hashes with a pepper.

Generator Crypto

Mode
Source

  • MD5 —
  • SHA-1 —
  • SHA-256 —
  • SHA-512 —

MD5 and SHA-1 are not collision-resistant. Use them for checksums, cache keys, and legacy interop — never for passwords or signatures.

Settings

How Hash Generator works

A cryptographic hash maps input of any length onto a fixed-length digest. The same input always yields the same digest, a one-character change produces a completely different one (the avalanche effect), and recovering the input from the digest is computationally infeasible. Hashing is one-way — there is no "unhashing".

The algorithms here differ sharply in what they are still fit for. MD5 and SHA-1 are broken for collision resistance: practical attacks can construct two different inputs with the same digest, so neither should be used for signatures or integrity against an adversary. They remain fine as fast, non-adversarial checksums — verifying a file copied cleanly off a disk, for instance. SHA-256 and SHA-512 have no known practical weaknesses and are the right default.

Passwords need something entirely different. General-purpose hashes are designed to be fast, which is precisely wrong for password storage: an attacker with a stolen database tries billions of candidates per second on a GPU. Argon2 is a memory-hard key derivation function — it deliberately consumes a configurable amount of RAM as well as time, which is what makes large-scale parallel cracking expensive rather than cheap.

Argon2id, the recommended variant, combines Argon2i’s resistance to side-channel attacks with Argon2d’s resistance to GPU cracking. Its cost parameters — memory, iterations, and parallelism — are tuned so a single verification takes a noticeable fraction of a second on your server. A pepper is a secret added to every password before hashing and stored separately from the database, so a stolen database alone is not enough to begin cracking.

Reference

  • MD5 → 128-bit digest (32 hex characters) — broken, checksums only
  • SHA-1 → 160-bit digest (40 hex characters) — broken, checksums only
  • SHA-256 → 256-bit digest (64 hex characters) — current default
  • SHA-512 → 512-bit digest (128 hex characters) — faster than SHA-256 on 64-bit CPUs
  • Argon2id(password ‖ pepper, salt, memory, iterations, parallelism) → password hash

How to use this generator

  1. Pick the algorithm

    SHA-256 for general integrity work, MD5 or SHA-1 only when matching a legacy checksum, Argon2 for passwords.

  2. Provide the input

    Type or paste text, or drop a file to hash its raw bytes — large files are streamed in chunks and never leave your device.

  3. Tune the cost (Argon2 only)

    Raise memory and iterations until a single hash takes 200–500 ms on your target hardware, then keep those parameters.

  4. Compare the digest

    Paste the expected value to compare. A single differing character means the content differs.

Worked examples

Verifying a download

Given
An ISO file and the SHA-256 checksum published by the vendor
Result
Digests match — the file is byte-identical

Only meaningful if the checksum came over a channel an attacker could not also modify. A checksum on the same page as the download proves very little.

The avalanche effect

Given
"hello" and "hellp" under SHA-256
Result
2cf24dba5fb0a30e… versus 9c0c4dcb2f0b4dbb…

A one-letter change alters roughly half the output bits. There is no notion of two digests being "close".

Why Argon2 for passwords

Given
One million candidate passwords on a GPU
Result
SHA-256: seconds. Argon2id at 64 MB: hours to days.

The memory requirement is what breaks GPU parallelism — cards have far more cores than they have RAM to feed them.

When to use it

  • Verifying that a downloaded file matches the publisher’s checksum.
  • Confirming two files are identical without comparing them byte by byte.
  • Generating cache keys or content-addressed identifiers from file contents.
  • Producing Argon2id hashes to test a password-storage implementation.
  • Reproducing a legacy MD5 or SHA-1 value while migrating a system off it.

Things to watch out for

  • Hashing is one-way. So-called hash "decrypters" are lookup tables of previously hashed common inputs, not reversal.
  • Never store passwords with a plain hash, salted or not. Use Argon2id, scrypt, or bcrypt — the speed of SHA-256 is what makes it wrong for the job.
  • MD5 and SHA-1 collisions are practical and cheap. Do not use either where an adversary chooses the input.
  • A checksum only proves integrity if it reaches you through a channel the attacker cannot alter. Otherwise it proves the file matches whatever they wanted it to match.

Frequently asked questions

Can a hash be reversed?

No. Hashes are one-way by construction. Sites claiming to "decrypt" a hash are searching precomputed tables of common inputs — which is exactly why unique salts defeat them.

Is MD5 still safe to use?

Not against an adversary. Collisions can be produced in seconds, so MD5 is unusable for signatures, certificates, or deduplication where inputs are attacker-controlled. As a non-adversarial checksum for accidental corruption it remains adequate.

Why should I not hash passwords with SHA-256?

Because SHA-256 is fast, and a stolen database is attacked offline at billions of guesses per second. Password hashing needs a deliberately slow, memory-hard function — Argon2id, scrypt, or bcrypt — so each guess costs the attacker real resources.

What is a pepper, and how does it differ from a salt?

A salt is unique per password and stored alongside the hash; it stops one cracking run from covering every account at once. A pepper is a single secret shared by all passwords and stored outside the database — in a config file or an HSM — so a database dump alone gives an attacker nothing to crack.

Are my files uploaded when I hash them?

No. Files are read locally and hashed in your browser with a WebAssembly implementation, in chunks, so even multi-gigabyte files are processed without leaving your device.

What Argon2 parameters should I use?

Start from the OWASP guidance — 19 MB of memory, 2 iterations, 1 degree of parallelism for Argon2id — then raise memory until a single hash takes 200–500 ms on your production hardware. Store the parameters with the hash so you can raise them later.

Related Developers tools

All developer tools