Generar hash
Hash Generator computes MD5, SHA-1, SHA-256, SHA-384, SHA-512, CRC32 and HMAC in your browser. Every result carries the algorithm's security status, because the single most consequential fact about MD5 and SHA-1 is that both are broken — and a tool that offers them without saying so is part of the problem.
La interfaz de esta herramienta está en inglés.
| Algorithm | Status | Digest | Copy |
|---|---|---|---|
| MD5128 | broken | … | |
| SHA-1160 | broken | … | |
| SHA-256256 | current | … | |
| SHA-384384 | current | … | |
| SHA-512512 | current | … | |
| CRC3232 | checksum | … |
La guía de abajo solo está disponible en inglés.
How does Hash Generator work?
A hash maps any input to a fixed-length value such that finding two inputs with the same output should be infeasible. “Should be” is doing a lot of work in that sentence, and which algorithms still satisfy it is the most useful thing this page can tell you.
MD5 and SHA-1 are broken, and it is not theoretical
MD5 collisions can be produced on a laptop in seconds, and were used in the wild: the Flame malware forged a Microsoft code-signing certificate with an MD5 collision in 2012. SHA-1 fell in 2017 when Google and CWI produced two PDFs with the same digest, and the cost has dropped since. Neither is acceptable for a signature, for integrity against an adversary, or for deduplicating input you do not control. Both are fine as non-security checksums, and both are still everywhere, which is why they are here.
A hash is not a password hash
SHA-256 is designed to be fast — billions of operations per second on a GPU — and speed is precisely wrong for a password, where the defence is being slow enough that guessing costs more than the password is worth. Storing SHA-256 of a password, salted or not, means an attacker with the database tries the entire common-password list in minutes. The right tools are bcrypt, scrypt and Argon2, all of which have a deliberate cost factor. Nothing on this page is a password hash.
HMAC is not “hash the key and the message”
The obvious construction, H(key || message), is broken on any Merkle–Damgård hash — which includes MD5, SHA-1 and SHA-256. An attacker who knows the digest and the key's length can append data and compute a valid digest for the extended message without ever seeing the key. This is the length-extension attack, and it is why HMAC exists as a separate primitive with its nested inner and outer hashes. SHA-384 and SHA-512/256 are immune by construction, being truncated.
The encoding of the input changes the hash
Hashing is defined over bytes, not characters, so the digest of café depends on whether the accented character is the two UTF-8 bytes C3 A9 or the single Latin-1 byte E9. This page uses UTF-8 throughout, which is what every current system means. A signature that verifies locally and fails in production is very often this.
CRC32 is not a hash at all
It is an error-detecting checksum designed for transmission faults, and it is trivial to construct a collision on purpose. With only 32 bits it also collides by accident after roughly 65,000 inputs, by the birthday bound. Correct for catching a corrupted download; wrong for anything else.
Input
abc
Digests
MD5 900150983cd24fb0d6963f7d28e17f72 broken SHA-1 a9993e364706816aba3e25717850c26c9cd0d89d broken SHA-256 ba7816bf8f01cfea414140de5dae2223b0… current
What options and edge cases does Hash Generator support?
| Parameter | Type | Default | Behaviour & edge cases |
|---|---|---|---|
| MD5 | 128-bit | broken | Collisions are practical on a laptop and have been used in real attacks. Fine as a non-security checksum; never for signatures, integrity against an adversary, or deduplication of untrusted input. |
| SHA-1 | 160-bit | broken | SHAttered produced a real collision in 2017 and the cost has fallen since. Browsers and certificate authorities have dropped it. Git still uses it for object names, which is a compatibility decision rather than a security one. |
| SHA-256 | 256-bit | current | The current default for integrity and signatures. No practical attack. Fast by design, which is why it is the wrong choice for hashing a password. |
| SHA-384 | 384-bit | current | SHA-512 truncated, which makes it immune to the length-extension attack that affects SHA-256. Chosen where that property matters. |
| SHA-512 | 512-bit | current | Faster than SHA-256 on 64-bit hardware, despite the larger output. Worth preferring where the extra length is not a cost. |
| CRC32 | 32-bit | checksum | An error-detecting checksum, not a hash. Trivial to forge deliberately and collides by accident after about 65,000 inputs. Correct for catching a corrupted transfer and wrong for everything else. |
| HMAC | keyed | SHA family only | A keyed construction that resists length extension, unlike hashing a key and a message together. Offered for the SHA algorithms; MD5 and CRC32 are excluded because HMAC over a broken hash is a broken MAC. |
| Input encoding | UTF-8 | always | Hashing is defined over bytes. A digest of the same text differs between UTF-8 and Latin-1, which is a recurring cause of signatures that verify locally and fail in production. |
| Output | hex or base64 | hex | The same bytes in two renderings. Hex is what command-line tools print; base64 is what many HTTP headers carry. |
Frequently asked questions
Can I use this to hash passwords?
No — and this is the most important answer on the page. Every algorithm here is designed to be fast, and speed is exactly what you do not want for a password: an attacker with your database and a GPU tries billions of candidates per second. Use bcrypt, scrypt or Argon2, all of which have a tunable cost factor that makes each guess expensive. Salting a SHA-256 helps against rainbow tables and does nothing against a modern cracking rig.
Is MD5 really broken if it is still used everywhere?
Both are true. Collisions are practical — you can produce two files with the same MD5 on a laptop — and MD5 collisions were used in a real attack to forge a Microsoft code-signing certificate. It remains everywhere as a non-security checksum, in ETags and file-integrity checks against accidental corruption, and that use is fine. What is not fine is anything where an adversary chooses the input.
Why does my digest differ from another tool's?
Almost always the input, not the algorithm. Check for a trailing newline — a file ends with one and a text box usually does not, and a single byte changes everything. Then check the encoding: this page uses UTF-8, and a tool defaulting to Latin-1 will give a different digest for any non-ASCII character. Finally check whether the other tool hashed the file's bytes or its base64 representation.
What is HMAC for?
Proving that a message came from someone holding a shared secret and was not modified. It is what signs a webhook payload, an API request and a session cookie. The reason it is a distinct primitive rather than just hashing the key with the message is length extension: with most hashes, knowing H(key || message) lets an attacker compute a valid digest for a longer message without the key. HMAC's nested construction prevents that.
Which SHA should I use?
SHA-256 unless you have a reason otherwise — it is the default everywhere, well analysed and fast enough. SHA-512 is genuinely faster on 64-bit hardware despite the longer output. SHA-384 is SHA-512 truncated, which makes it immune to length extension, and is the right pick if you are building something that hashes a secret directly rather than using HMAC.
Is my input uploaded?
No. SHA hashing uses the browser's built-in SubtleCrypto; MD5 and CRC32 are implemented in JavaScript on this page because SubtleCrypto deliberately refuses to implement MD5. Nothing leaves the tab, which matters because the things people hash are frequently API secrets, tokens and file contents.