Hash Generator

How Hash Functions Work

A cryptographic hash function takes an input of any length and returns a fixed size string of bytes, called a digest or a hash. The transformation is designed to be a one way street: computing the digest from the message is trivial, and recovering the message from the digest is meant to be impossible in any practical sense. Every algorithm in this tool, MD5, SHA-1, SHA-256, SHA-384, and SHA-512, is built on that same promise, and they differ mainly in how well the promise still holds.

Five properties define what a cryptographic hash is supposed to deliver. It must be deterministic, so the same input always yields the same digest on every machine and in every implementation. It must produce a fixed output size, so a one byte file and a ten gigabyte file both hash to the same number of characters. It must exhibit the avalanche effect, so that flipping a single input bit changes roughly half the output bits with no discernible pattern. It must be preimage resistant, meaning that given a digest there is no feasible way to find any message producing it. And it must be collision resistant, meaning nobody can find two distinct messages sharing a digest.

Collisions certainly exist. There are infinitely many possible inputs and only 2^256 possible SHA-256 outputs, so by the pigeonhole principle countless messages share every digest. Security rests entirely on nobody being able to find such a pair. That is exactly where MD5 and SHA-1 failed while SHA-2 continues to hold.

Mechanically, every algorithm here uses the Merkle-Damgard construction. The message is padded to a whole number of blocks, with the final block carrying an encoding of the original message length. An internal state is initialized to fixed constants, then a compression function absorbs one block at a time, mixing the block into the state through a series of rounds built from rotations, XORs, modular additions, and small nonlinear boolean functions. When the last block has been absorbed, the state is serialized and printed as hexadecimal.

The differences between the algorithms are entirely in those parameters. MD5 keeps a 128-bit state and runs 64 operations over 512-bit blocks. SHA-1 widens the state to 160 bits and the schedule to 80 rounds. SHA-256 moves to eight 32-bit words and 64 rounds with a much stronger message schedule. SHA-512 doubles everything to 64-bit words and 1024-bit blocks over 80 rounds, which is why it is often faster than SHA-256 on 64-bit hardware despite the larger output. SHA-384 is SHA-512 with different initial values and a truncated result.

One shared consequence of the Merkle-Damgard design is length extension: given the digest of an unknown message and its length, an attacker can compute the digest of that message with a suffix appended, without knowing the original. This affects all five algorithms and is the reason you should never authenticate data by hashing a secret concatenated with it.

Hash Algorithm Comparison

Every algorithm this tool supports, side by side. Output length is the quickest practical way to identify an unknown digest.

Broken here means specifically that collision resistance has fallen. Both MD5 and SHA-1 still resist preimage attacks, which is why they remain marginally usable as non adversarial checksums. That is a narrow exemption, not a defence.

Example Hashes of the Same Input

The word hello, hashed with three different algorithms. Nothing about the input changes, only the algorithm, and the results are unrelated strings of very different lengths.

Enter hello in the generator above and switch algorithms to reproduce all three. Then change the input to Hello, capital H, one bit of difference. Every digest changes completely, and none of them resembles its previous value. That is the avalanche effect at work, and it is what lets a digest act as a tamper evident seal: there is no way to make a small controlled change to the output by making a small change to the input.

Choosing the Right Hash Algorithm

Most of the decision comes down to one question: does an attacker gain anything by finding two inputs with the same digest? If yes, you need SHA-2. If no, almost anything works and speed can decide.

Appropriate uses

• SHA-256 as the default for anything new. It is secure, universally supported, hardware accelerated on modern CPUs, and produces a manageable 64 character digest.
• SHA-512 or SHA-512/256 for high throughput hashing on 64-bit servers, where the 1024-bit block size gives it a real speed advantage.
• SHA-384 when pairing with a P-384 elliptic curve or when a protocol specifies it, since matching digest strength to key strength is conventional practice.
• MD5 for non security fingerprints only: cache keys, deduplication, ETags, and detecting accidental file corruption.
• SHA-1 only where an existing system forces it, such as Git object identifiers or TOTP two factor codes, which use HMAC-SHA1 by specification.
• HMAC with SHA-256 or SHA-512 whenever a message needs to be authenticated rather than merely fingerprinted.

Do not use it for

• MD5 or SHA-1 for signatures, certificates, or anything where a collision helps an attacker. Practical collisions exist for both.
• Any of these algorithms, on their own, for password storage. That deserves its own discussion below.
• Hashing low entropy values such as email addresses or phone numbers and calling the result anonymized. The full candidate space can simply be enumerated.
• Secret prefix authentication, hashing a key followed by a message, on any Merkle-Damgard hash. Length extension breaks it. Use HMAC.
• Treating a hash as encryption. There is no key and no way back, so a digest cannot be decrypted, only guessed against.

A useful summary: use SHA-256 unless you have a specific reason not to, use SHA-512 when throughput on 64-bit hardware matters, use HMAC when a secret is involved, use a real KDF for passwords, and treat MD5 and SHA-1 as read only formats you interoperate with rather than choices you make.

Why You Should Not Hash Passwords With These Algorithms

This applies to every algorithm on this page, the broken ones and the secure ones alike, and the reason is the same in each case. General purpose hash functions are optimized for speed. Their intended job is to fingerprint large files at close to memory bandwidth, and both hardware and implementations have been tuned relentlessly toward that goal. Speed is the correct property there and exactly the wrong property for a password.

When a password database leaks, the attacker does not attack the mathematics. They guess. They take a wordlist, apply mangling rules, hash each candidate, and look for matches. Their success is determined purely by how many guesses per second the hardware allows, and with a general purpose hash the answer is billions on a single GPU. Since real password choices cluster heavily around a relatively small set of patterns, a large fraction of any leaked table falls within hours.

Salting is the first requirement and is not optional. Generate at least 16 random bytes per user, store them in plain text beside the hash, and include them in the hashed input. This ensures two users with the same password get different digests, so an attacker cannot crack the table in one pass, and it makes precomputed rainbow tables useless. What salting cannot do is make any single guess more expensive.

Making guesses expensive is the job of a password hashing function, and there are three worth using. Argon2id is the current recommendation from OWASP and the winner of the Password Hashing Competition. It is memory hard, requiring a configurable amount of RAM for every evaluation, which is what defeats GPU and ASIC attacks, because memory bandwidth is far harder to parallelize than raw arithmetic. scrypt is older and also memory hard. bcrypt is not memory hard but has an adjustable work factor, thirty years of scrutiny, and support in essentially every language. Where policy requires a FIPS approved primitive, PBKDF2-HMAC-SHA256 with a high iteration count is acceptable, and it is the one legitimate place a SHA-2 function belongs in a password pipeline.

Tune whichever you pick so a single hash takes roughly 100 to 500 milliseconds on your production hardware. A user logging in will never notice. An attacker running a wordlist will never finish.

HMAC and Keyed Hashing

A plain hash proves that data has not changed, but it proves nothing about who produced it, because anyone can recompute a digest after modifying the message. HMAC solves that by mixing a secret key into the hashing process. Defined in RFC 2104, it hashes the message twice: the key is XORed with an inner padding constant and prepended for the first pass, then XORed with an outer padding constant and prepended to that result for the second. The nested structure is deliberate, and it is what makes HMAC immune to the length extension problem that all Merkle-Damgard hashes share.

The result authenticates as well as verifies. A valid HMAC tag means both that the message arrived unaltered and that it was produced by someone holding the shared secret. That is a materially stronger claim than a bare checksum, and it is the guarantee that most API security actually rests on.

The uses are everywhere. JWTs signed with HS256, HS384, or HS512 are HMAC over the token header and payload. AWS Signature Version 4 derives a request specific key through a chain of HMAC-SHA256 operations. Webhook providers including Stripe, GitHub, and Shopify sign their payloads so receivers can confirm the callback is genuine. Web frameworks use HMAC for signed cookies and CSRF tokens, and TLS 1.3 uses it inside HKDF for key derivation.

Two rules when implementing. Always compare tags with a constant time comparison, never with ordinary string equality, since a normal comparison exits at the first mismatched byte and that timing difference is enough to forge a tag byte by byte. And prefer HMAC-SHA256 or better, since HMAC-SHA1 and HMAC-MD5 are not currently broken but have no reason to exist in new code. The generator above supports HMAC mode with your own secret key.

Each algorithm also has its own dedicated page, linked from the tools directory along with a JWT decoder for inspecting HMAC signed tokens and Base64, hex, and URL encoding utilities for the formats digests are usually carried in.