Hash Generator

What a hash is, and what it is not

A cryptographic hash maps input of any length to a fixed-length digest. The same input always produces the same digest, and changing a single bit changes the output completely. It is one-way: there is no operation that recovers the input from the digest.

That last property is why hashing is not encryption and cannot be used to store data you need back. It is why hashes are used for integrity checking, for deduplication, and for password storage, where the point is precisely that the original cannot be recovered.

Which algorithm to use

Algorithm	Digest	Status
MD5	128 bits	Broken. Collisions are trivial to produce.
SHA-1	160 bits	Broken. A practical collision was demonstrated in 2017.
SHA-256	256 bits	Current default for general use.
SHA-512	512 bits	Fine, and faster than SHA-256 on 64-bit hardware.

"Broken" here means a collision attack exists: an attacker can construct two different inputs with the same digest. That defeats any use where the hash is meant to prove authenticity, such as signatures or verifying a download against a published checksum from an untrusted source.

MD5 and SHA-1 remain reasonable for non-adversarial uses where you only need a cheap fingerprint: cache keys, detecting whether a file changed, sharding. They are included here because plenty of existing systems still emit them and you need to be able to check against those values.

Never use these for passwords

General-purpose hashes are designed to be fast, and speed is exactly the wrong property for password storage. Modern hardware computes billions of SHA-256 digests per second, so a stolen database of SHA-256 password hashes falls quickly to a dictionary attack.

Password storage needs a deliberately slow, memory-hard function with a per-user salt: bcrypt, scrypt or Argon2. These have a configurable work factor that can be raised as hardware improves. If you are reaching for SHA-256 to store a password, reach for Argon2 instead.

Verifying a download

Paste the published checksum into the compare box. A match confirms your copy is byte-identical to the one the publisher hashed. Two caveats: the checksum must come from a trustworthy channel, because an attacker who can replace the file can usually replace a checksum published beside it, and if the published value is MD5 or SHA-1 it proves only that the file is not corrupted, not that it has not been tampered with.

Encoding affects the digest

A hash is computed over bytes, not characters, so text must be encoded first. This tool uses UTF-8, which is what almost every other system uses by default. If a digest computed elsewhere does not match, an encoding difference is the usual explanation, along with a trailing newline: many command line tools hash a file that ends in a newline, while text pasted into a box often does not.

Questions

Can I reverse a hash to get the original text?

No. Hashing is one-way by design. Sites that appear to reverse hashes are looking the digest up in a precomputed table of common inputs, which works only for short or predictable values.

Is MD5 safe to use?

Not where an attacker is involved. Collisions can be produced deliberately, so MD5 must not be used for signatures or for verifying authenticity. It is still fine as a cheap fingerprint for cache keys or change detection.

Should I use SHA-256 for passwords?

No. It is far too fast, so a stolen database can be attacked at billions of guesses per second. Use bcrypt, scrypt or Argon2, which are deliberately slow and take a per-user salt.

Why does my hash differ from the one my terminal produced?

Usually a trailing newline. Command line tools hash the file exactly as stored, and most text files end with a newline that a pasted selection omits. Character encoding differences are the other common cause.

Is the text I hash sent to a server?

No. MD5 is implemented in JavaScript on this page and the SHA family uses your browser's built-in crypto. Both run locally and no request is made.