Hash Generator

What is hashing?

A cryptographic hash function takes an input of any size — a single word, a password, a 4 GB video — and produces a fixed-length string of bytes called a hash, digest or checksum. SHA-256, for example, always outputs exactly 256 bits (32 bytes, shown as 64 hexadecimal characters) no matter whether the input is empty or enormous. The same input always produces the same output, and even a one-bit change to the input produces a completely different, unpredictable-looking digest. This property — that a tiny change cascades into a totally different result — is called the avalanche effect.

The crucial feature of a cryptographic hash is that it is a one-way function. It is fast and easy to compute the hash of some data, but practically impossible to run the process backwards and recover the original data from the hash alone. A good hash also makes it infeasible to find two different inputs that produce the same digest (a collision), or to find any input that produces a specific target digest (a preimage). These guarantees are what let hashes act as compact, tamper-evident fingerprints for data.

Because the output is fixed-size and deterministic, hashes are perfect for comparing, indexing and verifying data without handling the data itself. Instead of transmitting a whole file to check it matches, you can compare its short hash. Instead of storing a password, you can store a derived hash. Instead of trusting that a download is intact, you can recompute its hash and compare it to the published value. This Hash Generator computes all of these digests instantly and entirely inside your browser.

It is important to understand what hashing is not. Hashing is not encryption: there is no key and no way to decrypt a hash back into the original message, by design. It is also not a substitute for a slow password-hashing function on its own — raw SHA-256 is far too fast for storing passwords safely. Understanding these boundaries is the difference between using hashes correctly and introducing a serious security hole.

Hashing vs encryption: what is the difference?

Hashing and encryption are often confused because both transform readable data into something unreadable, but they solve opposite problems. Encryption is a two-way, reversible process: you scramble plaintext into ciphertext with a key, and anyone with the right key can decrypt it back to the original. The whole point of encryption is confidentiality — keeping data secret while preserving the ability to recover it later. AES and RSA are encryption algorithms.

Hashing is a one-way, irreversible process with no key and no decryption. You cannot “un-hash” a digest to recover the input, and that is exactly the intent. The point of hashing is integrity and identity — proving that data has not changed and creating a compact fingerprint — not secrecy. If someone tells you they will “decrypt the MD5” of a value, they are mistaken about how hashing works; at best they can look the value up in a precomputed table of common inputs.

A simple way to remember it: encrypt data you need to read again later (a stored document, a message in transit); hash data you only need to verify or compare (a password check, a file checksum, a digital signature). The two are frequently combined — for instance, a digital signature hashes a document and then encrypts the hash with a private key — but they remain distinct tools with distinct guarantees.

MD5 vs SHA-1 vs SHA-256: which should you use?

MD5 produces a 128-bit digest and is blazingly fast, which is why it survives in legacy systems for non-security tasks like detecting accidental file corruption or deduplicating data. But MD5 is cryptographically broken: researchers can generate two different inputs with the same MD5 hash almost instantly, and have used this to forge certificates. Never use MD5 to verify authenticity, store passwords or sign anything. Treat it purely as a fast, non-secure checksum.

SHA-1 produces a 160-bit digest and was the workhorse of the web for years, but it is also broken. The 2017 “SHAttered” attack produced two different PDFs with the same SHA-1 hash, and the cost of such attacks has only fallen since. Browsers and certificate authorities have removed SHA-1 from TLS, and Git is migrating away from it. Like MD5, SHA-1 is acceptable only for legacy interoperability and non-security checksums, never for new security-sensitive work.

SHA-256 — part of the SHA-2 family — produces a 256-bit digest and has no known practical weaknesses. It is the modern default for file integrity, digital signatures, TLS certificates, blockchains and software distribution. For almost every situation where you need “a secure hash,” SHA-256 is the right answer; choose SHA-512 if you want an even larger security margin or are running on 64-bit hardware where it can be faster. If you want a hash built on a completely different mathematical design as a hedge against future SHA-2 weaknesses, reach for SHA3-256.

When should you use SHA-512, SHA-3 or BLAKE2?

SHA-512 is part of the same SHA-2 family as SHA-256 but works internally with 64-bit words and a 512-bit output. On modern 64-bit processors it is often as fast as or faster than SHA-256 while offering a larger security margin, which makes it a good choice for long-lived archives, high-assurance signatures and anywhere you simply want more output bits. SHA-384 and SHA-512/256 are truncated variants of the same core; SHA-512/256 has the bonus of being immune to the length-extension quirk that affects SHA-256.

SHA-3 (Keccak) was standardised in 2015 as an alternative built on a completely different “sponge” construction rather than the Merkle–Damgård design used by MD5, SHA-1 and SHA-2. Because its internals are unrelated, any future cryptanalytic breakthrough against SHA-2 is unlikely to apply to SHA-3, so it is valued as a diversified, future-proof option. It is also naturally immune to length-extension attacks. SHA3-256 and SHA3-512 are excellent modern choices when you want a standardised hash with a different pedigree.

BLAKE2 (and its successor BLAKE3) is a modern, extremely fast hash that frequently outperforms even MD5 while providing security comparable to SHA-3. BLAKE2b is tuned for 64-bit platforms and BLAKE2s for smaller 32-bit and embedded devices. Both include a built-in keyed mode, so they can act as a message authentication code directly, without the separate HMAC construction. If raw speed with strong security matters — hashing large volumes of data, content addressing, integrity checks at scale — BLAKE2 is an outstanding pick.

Password hashing: why a plain hash is not enough

It is tempting to store user passwords as a simple SHA-256 hash, but doing so is a serious mistake. General-purpose hashes are designed to be fast, and modern hardware can compute billions of SHA-256 hashes per second. An attacker who steals a database of fast hashes can crack weak and even moderately strong passwords very quickly using brute force, dictionaries and precomputed “rainbow tables.” Speed, the very thing that makes SHA-256 great for file integrity, is exactly what makes it dangerous for passwords.

Two ingredients fix this. A salt is a unique random value added to each password before hashing, which guarantees that identical passwords produce different hashes and defeats precomputed tables. A work factor deliberately makes the function slow and memory-hungry, so each guess costs the attacker meaningful time and resources. Password-specific algorithms — bcrypt, scrypt, PBKDF2 and the modern winner Argon2 — bundle salting and a tunable cost together. They are built on top of the same primitives but are engineered to be expensive on purpose.

The rule of thumb is simple: use a fast cryptographic hash like SHA-256 or BLAKE2 for integrity and fingerprints, and use a slow, salted password-hashing function like Argon2 or bcrypt for storing passwords. This Hash Generator is built for the first job — verifying data and learning how the algorithms behave — not for hashing production passwords, which should always go through a dedicated, slow KDF on your server.

Data integrity and checksum verification

The everyday superpower of hashing is verifying that data has not changed. When a project publishes a download, it usually also publishes the file’s SHA-256 checksum. After downloading, you recompute the hash locally and compare it to the published value: if they match, the file is bit-for-bit identical to what the author released; if they differ by even a single character, the file is corrupted or has been tampered with and should not be trusted. This Hash Generator’s file mode and verification panel do exactly this, entirely on your device.

Checksums catch both accidental and deliberate changes. A flaky network connection, a failing disk or an interrupted transfer can silently corrupt a file, and a mismatched hash reveals it immediately. More importantly, an attacker who compromises a mirror or performs a man-in-the-middle attack can swap a legitimate download for a malicious one — but unless they also control the channel that publishes the checksum (ideally protected by a signature), the hashes will not match. This is why reproducible builds and signed checksums are cornerstones of supply-chain security.

The same principle scales up to whole systems. File-integrity monitoring tools record baseline hashes of critical files and re-check them on a schedule, alerting administrators when something changes unexpectedly. Backup and archival systems store hashes alongside data to detect silent “bit rot” over years of storage. Content-addressed systems like Git, IPFS and container registries use the hash of content as its very address, so integrity verification is built into how data is named and retrieved.

What is HMAC and when do you need it?

A plain hash proves that data has not changed, but it does not prove who produced it — anyone can compute the SHA-256 of a message. HMAC (Hash-based Message Authentication Code) solves this by mixing a secret key into the hashing process in a specific, carefully designed way defined in RFC 2104. The result, such as HMAC-SHA256, can only be produced or verified by someone who knows the shared secret key, so it proves both integrity (the message is unchanged) and authenticity (it came from a holder of the key).

HMAC is everywhere in modern APIs. When you call a service like AWS, Stripe or the GitHub webhooks API, requests are signed with HMAC: the sender computes an HMAC of the request using a secret key, and the receiver recomputes it to confirm the request is genuine and untampered. JSON Web Tokens signed with the “HS256” algorithm use HMAC-SHA256. Because HMAC is a keyed construction, it resists the length-extension attacks that can affect naively concatenating a key with a message and hashing it.

This tool implements the real HMAC construction, not a shortcut. Switch on HMAC, enter your secret key (as text, hex or Base64), and generate HMAC-MD5, HMAC-SHA1, HMAC-SHA256 or HMAC-SHA512 to test webhook signatures, debug API authentication or learn how keyed hashing works. As always, the key and data never leave your browser — making it a safe place to experiment with real secrets while developing.