Hash Generator — Free Online Tool on Toolpile
Every tool you need, one place
PDF, Image, AI, Dev, and Business tools — free, private, no signup.
Toolpile uses cookies for analytics and ads. The tools themselves keep your files in the browser — that doesn't change. Read the full policy
PDF, Image, AI, Dev, and Business tools — free, private, no signup.
About Hash Generator
A hash function is a one-way fingerprint: any input produces a fixed-size output, the same input always produces the same output, and you cannot reverse the output back to the input. That last property makes hashes useful for password storage, file integrity checks, deduplication, and digital signatures — and useless for things people regularly try to use them for, like "hiding" data. Here's the working model and the practical tradeoffs between MD5, SHA-1, SHA-256, and the rest.
A cryptographic hash function takes any input — a string, a file, a million-character document — and produces a fixed-length output (the digest). MD5 produces 128 bits, SHA-1 produces 160, SHA-256 produces 256, SHA-512 produces 512. The output looks random, but it's deterministic: hashing `"hello"` with SHA-256 always produces `2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824`. Change one character — `"Hello"` — and the output changes completely (`avalanche effect`). Roughly half the bits flip.
Three properties define a cryptographic hash: **pre-image resistance** (given a hash, you can't find an input that produces it), **second pre-image resistance** (given an input + its hash, you can't find a different input with the same hash), **collision resistance** (you can't find any two different inputs that produce the same hash). When a hash function is "broken", at least one of those properties has practical attacks against it.
Hashes are not encryption — there's no key, no decryption, no way to recover the input. They're not compression — the output is the same size regardless of input. They're a fingerprint: identifies content, not stores it. Hashing a 1 GB file gives you 64 hex characters; you can't turn those 64 characters back into the file.
**MD5** (1991, 128-bit) is broken for cryptographic use. Practical collision attacks have existed since 2004; in 2008 researchers built a fake CA certificate exploiting MD5 collisions. Do not use MD5 for password hashing, digital signatures, or anything security-relevant. It's still fine as a fast non-cryptographic checksum (file deduplication, cache keys, content-addressable storage where the input is non-adversarial).
**SHA-1** (1995, 160-bit) is also broken. Google's 2017 SHAttered attack produced two different PDFs with the same SHA-1 hash. Browsers stopped accepting SHA-1 certificates the same year. Same recommendation as MD5 — don't use for security; fine for non-adversarial integrity checks.
**SHA-256** (2001, 256-bit) is the modern default. No practical attacks against it as of 2026. Used for Bitcoin (every block hash), TLS certificates, file integrity (the hashes published next to every Linux ISO), and most digital signature schemes. When a system says "compute a hash" without specifying, SHA-256 is the right answer.
**SHA-512** (2001, 512-bit) is SHA-256's bigger sibling — same structure, larger output. Slightly faster than SHA-256 on 64-bit CPUs (it operates on 64-bit words natively), slightly slower on 32-bit. Use when you specifically need 512-bit output (some signature schemes, some HMAC constructions). For general-purpose hashing, SHA-256 is the convention.
**SHA-3** (2015) is a different family — Keccak sponge construction, designed as a hedge if SHA-2 were ever broken. Not yet widely deployed; SHA-256 still dominates. Worth knowing exists; rarely the right choice unless your use case specifically requires it.
If you're hashing a password to store it, **don't use SHA-256 directly**. SHA is fast — that's the bug. A modern GPU computes ~10 billion SHA-256 hashes per second. Stolen password databases get cracked at that speed against any common password. The fix isn't a stronger SHA — it's a deliberately slow function: bcrypt, scrypt, Argon2id, or PBKDF2.
Bcrypt (1999) is the conservative choice — slow by design, adjustable cost factor that scales as hardware improves. Argon2id (2015, Password Hashing Competition winner) is the modern recommendation — designed to resist GPU and ASIC attacks via memory-hard computation. Both are 1000-100,000× slower per hash than raw SHA-256, which makes mass cracking economically infeasible.
This tool computes raw SHA hashes — useful for file integrity, content fingerprinting, and learning. If you need to hash a password for storage, use a server-side library that exposes Argon2 or bcrypt; never roll your own with raw SHA.
Why do I get the same hash for the same input?
Because that's the entire point of a hash function — deterministic. Same input always produces same output, on any device, in any language, in any year. This determinism is what makes hashes useful for verification: you compute the hash on your end, the publisher computed the hash on their end, the values match if the file is unchanged.
Can someone reverse my hash to get the original input?
Not directly — hashes are one-way. But for low-entropy inputs (a common password, a short string), an attacker can compute hashes of every possible input and look up yours in a rainbow table. SHA-256 of `password` is the same on every machine; that hash is well-known. To resist this, salt your input (prepend a random per-record string before hashing) and use a slow KDF like Argon2 instead of raw SHA. Random high-entropy inputs (long files, UUIDs, secret keys) are practically un-reversible.
Is the output uppercase or lowercase hex?
Both are valid — they encode the same bytes. Lowercase is more common (Unix convention, OpenSSL default, most published checksums). Uppercase shows up in some Windows tools and older APIs. If you're comparing two hashes and one is uppercase, the other lowercase, normalise both to the same case before comparing.
Why does my MD5 of a file differ between tools?
Almost always because of trailing whitespace or line-ending differences (CRLF vs LF). Hashing is byte-exact — even an invisible newline at the end of a file changes the hash completely. To verify a published file checksum, ensure your local copy is byte-identical to the original (most published hashes assume the file is exactly what was uploaded, no editor touch-ups).
What's the difference between hashing and HMAC?
HMAC (Hash-based Message Authentication Code) is a hash with a secret key mixed in. Plain SHA-256 of a message proves the message hasn't changed; HMAC-SHA-256 proves the message hasn't changed AND came from someone who knows the key. Used for API request signing, JWT signatures, webhook authentication. If a system says "sign with HMAC-SHA-256", you need a separate tool that takes both a key and a message — raw hashing tools won't do it.