# Hash generator

URL: https://www.toolflux.app/en/hash-generator/
Stand: 2026-06-05

Hash generator for 8 algorithms at once - SHA-2/3, BLAKE2/3, MD5. Status badges, avalanche demo, file hashing up to 50 MiB. Local in your browser.

A good hash function behaves like a one-way street: the same input always produces the same digest, a tiny input change usually flips about half the output bits, and you can't recover the input from the digest. The generator below shows eight algorithms at once - with status badges, speed bars, and an avalanche demo that lives up to its name. Most importantly, the biggest sign at the top: hashes are not for passwords.

## Which hash function is the right pick in 2026?

For greenfield work the answer is short: **SHA-256** if you want the standard, **BLAKE3** if you need speed, **SHA3-256** if you need design diversity for compliance.

| Algorithm | Output | Status | When |
|---|---|---|---|
| MD5 | 128 bit | Broken (2004) | File integrity without an adversary, cache keys |
| SHA-1 | 160 bit | Broken (2017) | Git object IDs, legacy interfaces |
| SHA-256 | 256 bit | Current | TLS, signatures, Bitcoin, almost everything |
| SHA-384 | 384 bit | Current | Higher security margin, CNSA profiles |
| SHA-512 | 512 bit | Current | When output length matters or 64-bit CPUs |
| SHA3-256 | 256 bit | Modern | Design diversity from SHA-2, compliance profiles |
| BLAKE2b | 512 bit | Modern | High-throughput, Argon2 internals |
| BLAKE3 | 256 bit | Modern | Fast in native/SIMD builds, parallelisable |

**Broken** means: practical collisions are demonstrated - two distinct inputs with the same hash can be constructed. That makes the algorithm useless for signatures, but file integrity against transmission errors still works. Pre-image resistance (hash → input) for MD5 and SHA-1 still holds in practice.

## Why hashes aren't password hashers

The biggest sign on the tool is the most important message: **SHA-256 is not a password hasher.** The math is the same; the use case wants the opposite of "fast".

A general-purpose hash is optimised for speed. A modern GPU tests around 10¹⁰ SHA-256 candidates per second. If your database is stolen and passwords are stored as `SHA-256(password)`, many human-chosen or alphanumeric 8-character passwords (62⁸ combinations, ~6 hours worst case) fall in hours. The full printable ASCII space (95⁸) holds out for days, but typical passwords carry far less entropy than their length suggests.

Password hashers do the opposite: deliberately slow (configurable cost in CPU and memory) and salted. Three current options:

- **bcrypt** - 1999, configurable cost factor (typically 12-14), 72-byte input limit.
- **scrypt** - 2009, additionally memory-hard, hard to accelerate on GPUs.
- **Argon2** - 2015 PHC competition winner, three variants (i/d/id), memory and parallelism parameters.

If you're building a new login system, pick Argon2id or bcrypt - not SHA-256.

## HMAC - hash with a key

HMAC is a construction that cleanly mixes a secret key into a hash. `HMAC-SHA-256(key, message)` returns a 256-bit value that only someone holding the key can reproduce.

The naive approach - `SHA-256(key || message)` - is vulnerable to length-extension attacks on Merkle-Damgård hashes (MD5, SHA-1, SHA-2). HMAC sidesteps this with two nested hash calls and fixed padding constants:

```
HMAC(K, m) = H((K' ⊕ opad) || H((K' ⊕ ipad) || m))
```

In practice: use HMAC anywhere you need a keyed hash. AWS Signature v4, GitHub webhooks, Stripe webhooks, JWT HS256 - they all use HMAC. The HMAC function in @noble/hashes or the browser's `crypto.subtle.sign` API hides the construction; you pass key and message.

## Hashing files locally

Set the mode to "File" above, then pick or drag a file. The 50 MiB cap is generous for the typical use cases. The file is read in your browser, hashed by all 8 algorithms, and the comparison table populates. The file is not uploaded - that's the advantage over online hash services that do exactly that.

Common use cases:

- **Verifying ISO downloads.** Ubuntu, Debian, NixOS and others publish SHA-256 digests. Hash locally, compare, done.
- **Backup integrity.** Periodically rehash a `.tar.gz` or `.zip` and compare with the original digest to detect bit rot.
- **Pre-signature audit.** Before signing code or data, hash it to make sure you're signing the same bytes you have in your repo.

## Avalanche - what "good diffusion" actually feels like

The avalanche demo below flips the last bit of your input and compares digests. A good hash flips about 50% of the output bits - 128 of 256 in SHA-256, 64 of 128 in MD5.

The interesting part: even broken MD5 hits ~50% avalanche. Avalanche on its own is not a security measure. It only shows that output bits are well mixed. Security additionally requires that no one can construct two inputs with the same hash (collision resistance) - and that's exactly where MD5 and SHA-1 are broken.

The demo is still educational: it shows why a hash function feels like every input change scrambles everything. That property is what makes file integrity robust - a single flipped bit in a 4 GB file produces a completely different digest.

## SHA-3 - a second family in reserve

NIST selected Keccak as the SHA-3 competition winner in 2012 and standardised SHA-3 as FIPS 202 in 2015 - not because SHA-2 was unsafe, but as insurance. SHA-2 uses the Merkle-Damgård scheme (like MD5 and SHA-1); SHA-3 uses a sponge construction (Keccak). Should a generic attack on Merkle-Damgård ever surface, SHA-3 is already a fully different design in the standard.

In practice SHA-3 is slower than SHA-2 on most CPUs, because modern processors have SHA-2 acceleration instructions (Intel SHA-NI, ARMv8 SHA). If your code needs to be future-proof against Merkle-Damgård breakage, use SHA-3. Otherwise SHA-256.

## BLAKE3 and the speed bar

BLAKE3 was published in 2020 with an unusual trick: **tree-hashing**. The input is split into 1024-byte chunks, each chunk is hashed independently, then the chunk hashes are combined into a tree. That makes BLAKE3 highly parallel - modern CPUs hash multiple chunks at once via SIMD or across cores.

A note on the speed bar: this generator runs every algorithm in pure JavaScript (@noble/hashes). The well-known 5-10× lead BLAKE3 has over SHA-256 comes from native implementations with SIMD and multithreading (Rust, C). In the browser BLAKE3 is barely faster than SHA-256, sometimes slower - the architectural case still holds the moment you reach for it in an optimised backend.

## FAQ

### Which hash algorithm is safe today?

SHA-256 as the standard, SHA-512 or BLAKE3 for speed, SHA3-256 for design diversity. SHA-1 and MD5 have practical collisions (broken 2017 and 2004) and aren't fit for signatures.

### Why is MD5 unsuitable for passwords?

MD5 is a fast general-purpose hash. An attacker tests billions of candidates per second. Password hashers like bcrypt, scrypt, or Argon2 are deliberately slow and salted.

### What's the difference between SHA-256 and SHA-3?

Same output length (256 bit), different construction. SHA-256 uses Merkle-Damgård, SHA-3 uses a Keccak sponge. SHA-3 is a diversity reserve against future generic attacks on Merkle-Damgård.

### How do I hash a file locally?

Set the mode to "File" above and drag a file in. The file is read once, then all 8 digests are computed locally. Limit: 50 MiB.

### FAQ

**Which hash algorithm is safe today?**

For new applications: SHA-256 (standard), SHA-512 or BLAKE3. SHA3-256 as an alternative design for diversity. SHA-1 and MD5 have practical collisions - SHA-1 since 2017 (SHAttered), MD5 since 2004 (Wang). For passwords, never use a plain hash function - reach for bcrypt, scrypt, or Argon2.

**Why is MD5 unsuitable for passwords?**

MD5 is a general-purpose hash function: fast and unsalted. A modern attacker tests billions of MD5 candidates per second. Password hashers like bcrypt, scrypt, and Argon2 are deliberately slow (configurable cost), salt every password, and raise the cost of hardware acceleration substantially - the memory-hard schemes in particular shrink the GPU/ASIC advantage. SHA-256 has the same problem as MD5 here: too fast. The avalanche behaviour of a hash says nothing about its fitness for passwords.

**What's the difference between SHA-256 and SHA-3?**

Both produce 256-bit outputs but use different designs. SHA-256 uses Merkle-Damgård (like MD5, SHA-1, SHA-2). SHA-3 uses a sponge construction (Keccak); NIST picked Keccak as the SHA-3 competition winner in 2012 and standardised SHA-3 as FIPS 202 in 2015. SHA-3 isn't a replacement for SHA-256 but a diversity reserve - if a generic attack on Merkle-Damgård is ever found, SHA-3 is already standardised.

**How do I hash a file locally?**

Set the mode to 'File' in the generator above, then drag a file into the drop zone or click. The file is read in your browser and hashed, not uploaded. Limit: 50 MiB - the file is read once, then all 8 digests are computed locally. Useful for verifying ISO downloads or backup archives.

**What is HMAC and when do I need it?**

HMAC is a construction that mixes a hash with a secret key into an authentication tag. HMAC-SHA-256(key, message) returns a value only someone holding the key can reproduce. Use cases: API signatures (e.g. AWS Signature v4), webhook authentication (GitHub, Stripe), JWT HS256 tokens. On Merkle-Damgård hashes (MD5, SHA-1, SHA-2) a naive `hash(key || message)` is vulnerable to length-extension attacks - HMAC defends against that. SHA-3, BLAKE2 and BLAKE3 don't have the issue by construction, but HMAC stays the portable, RFC-standard choice.

**Is BLAKE3 actually faster than SHA-256?**

In optimised native implementations, yes - native BLAKE3 builds (Rust, C) scale tree-hashing across CPU cores and use SIMD; in backend benchmarks on GB-sized inputs BLAKE3 is often 5-10× faster than SHA-256 there. In the browser the picture flips: this generator runs pure JavaScript (@noble/hashes), and SHA-256 sits at a similar speed - sometimes even faster than BLAKE3. The architectural lead only shows up once you reach for BLAKE3 in an optimised backend.

**What is the avalanche effect in hash functions?**

The avalanche effect describes how much the digest changes when a single input bit flips. A good hash function flips about 50% of the output bits on average. The demo below flips the last bit of your input and counts the changed bits via Hamming distance. SHA-256 and BLAKE3 hit ~50%, SHA-1 and even broken MD5 do too - avalanche says nothing about collision resistance.