How to Generate MD5, SHA-256, and Other Hashes

Hashing converts any input (a password, a file, a message) into a fixed-length string of characters. The same input always produces the same hash, but even a tiny change in the input produces a completely different hash. This makes hashing essential for integrity verification, password storage, digital signatures, blockchain proofs, and dozens of other building blocks of modern computing. Picking the right algorithm, knowing why some are broken, and recognising the patterns that misuse hashes turn a five-second tool into a foundation you can build on safely.

A short history of hash functions

Hashing as a programming idea pre-dates cryptography by decades, hash tables in data structures use simple functions like CRC and FNV to spread keys across buckets. Cryptographic hashes, designed to be irreversible and collision-resistant, emerged in the late 1980s with Ron Rivest's MD4 (1990) and MD5 (1991). MD5 became the de facto standard for two decades before practical collisions made it unsafe for security work.

NIST's SHA-0 (1993) was withdrawn almost immediately and replaced by SHA-1 (1995). SHA-1 held up better but fell in stages: theoretical attacks in 2005, a practical certificate-forgery scenario by 2009, and Google's SHAttered demonstration of two different PDFs with the same SHA-1 hash in 2017. The SHA-2 family (SHA-224, SHA-256, SHA-384, SHA-512), published in 2001, was designed as a longer-term replacement and remains secure today. SHA-3 (Keccak, standardised in 2015) is a structurally different design intended to provide a backup if SHA-2 ever falls.

In parallel, password-specific hashes evolved separately. Plain MD5 or SHA-1 turned out to be too fast for password storage, so bcrypt (1999), scrypt (2009), and Argon2 (2015, winner of the Password Hashing Competition) added deliberate slowness and memory-hardness to make brute-force attacks orders of magnitude more expensive. The right hash for a password is never the same as the right hash for a file checksum.

How hashing works

A hash function takes input of any size and produces output of a fixed size:

Notice that changing a single character (lowercase h to uppercase H) or adding a character completely changes the hash. This is called the avalanche effect and is what makes hashes useful for spotting any change, no matter how tiny.

Internally, a modern hash function divides its input into fixed-size blocks (64 bytes for SHA-256, 128 for SHA-512), feeds each block through a compression function, and chains the state forward. The output is the final state after the last block is mixed in. Because the chain depends on every byte, there is no shortcut that lets an attacker change the input without rewriting the entire hash.

A good cryptographic hash has three security properties: pre-image resistance (you cannot find an input that produces a given hash), second pre-image resistance (given one input, you cannot find a different input with the same hash), and collision resistance (you cannot find any two distinct inputs with the same hash). MD5 fails all three; SHA-1 fails collision resistance; SHA-2 and SHA-3 still hold all three.

Common hash algorithms

SHA-256 is the current standard for most general-purpose uses. MD5 and SHA-1 should only be used when interacting with legacy systems that require them; never for security boundaries. For passwords, use bcrypt or Argon2id, not raw SHA-256.

How to generate a hash

1. Choose your algorithm: select MD5, SHA-1, SHA-256, SHA-384, or SHA-512 from the dropdown. Use SHA-256 unless you have a specific reason to pick another.
2. Enter text or upload a file: type or paste text into the input box, or drop a file. The tool runs the hash entirely in your browser using the Web Crypto API.
3. Copy the hash: the result is a hex string you can use for verification, storage, or comparison. Many tools also offer base64 encoding for compact storage.
4. Compare if needed: paste the published hash next to your generated hash and let the tool flag the first character that differs. Visual comparison of 64-character strings is error-prone.

Practical uses

File integrity verification: download a file and compare its hash against the publisher's official hash. If they match, the file is authentic and uncorrupted. This is the use case that drives most everyday hash generation, the workflow behind every sha256sum invocation on Linux and every checksums page on a software download.

Password storage, applications store hashes of passwords, not the passwords themselves. When you log in, your input is hashed and compared to the stored hash. The crucial detail is that the algorithm must be slow on purpose (bcrypt, Argon2) so that an attacker who steals the hash file cannot brute-force it in a reasonable time.

Data deduplication: storage systems and backup tools hash chunks of data, often blocks of a few megabytes, and use the hash as a key. Two chunks with the same hash are assumed to be identical, so the second occurrence stores only a pointer. Tools like restic, borg, and many cloud backup services depend on this.

Digital signatures: a digital signature is a hash that has been encrypted with a private key. The verifier hashes the document, decrypts the signature with the public key, and checks that the two match. This proves both that the document has not changed and that the signer approved this exact version.

HMAC for API security: HMAC combines a hash function with a secret key, producing a tag that anyone with the same key can verify. Webhooks, AWS request signing, and many internal RPCs use HMAC-SHA256 so the receiver knows the request really came from a trusted source.

Blockchain and Merkle trees: cryptocurrencies, content-addressed storage (IPFS), and Git all use hash trees to commit to large data sets with a single root hash. Change one byte anywhere in the tree, and the root hash changes, which is the property that makes the data tamper-evident.

Cache keys: cache systems hash request URLs or query parameters to produce a compact lookup key. CRC and SipHash are common here because they prioritise speed over cryptographic guarantees.

Hash vs HMAC vs digital signature

These three concepts are often confused because they all output similar-looking hex strings.

A plain hash proves nothing about who created it. HMAC proves the sender had the shared secret. A signature additionally identifies the signer without needing to share the secret. Choose the weakest tool that solves your actual problem.

Common pitfalls

• Using MD5 or SHA-1 for security, both are cryptographically broken. Collisions can be generated in seconds (MD5) or hours on cloud hardware (SHA-1). Reserve them strictly for non-security checksums.
• Hashing passwords with general-purpose hashes, plain SHA-256 of a password is fast enough that an attacker with a stolen database can try billions of guesses per second on a GPU. Use bcrypt, scrypt, or Argon2id instead.
• **Forgetting to salt, two users with the same password should never produce the same stored hash. Salting (adding random bytes to each password before hashing) prevents this and stops rainbow-table lookups.
• **Trusting a hash served from the same place as the file, an attacker who compromises a download mirror can swap both the file and its hash. Whenever possible, fetch the hash from a different domain or verify a GPG signature over the hash list.
• **Hex vs base64 confusion, the same hash encodes to 64 hex characters or 44 base64 characters. Comparing different encodings will always fail. Match the encoding before comparing.
• **Comparing with == in security code, string comparison short-circuits on the first mismatched character, which leaks timing information. Use a constant-time compare function in any code that decides authentication.
• **Truncating a hash to save space, taking only the first 8 characters of SHA-256 cuts collision resistance from astronomical to trivial. Either store the full hash or use a hash designed for short outputs (SipHash).
• **Using a CRC for security, CRC32 is great at catching accidental corruption but trivial to forge. Anyone can append bytes to make any CRC come out to any chosen value.
• **Re-hashing instead of using PBKDF, looping SHA-256 ten thousand times by hand is the classic homemade password hash; it leaks timing and is much slower than the well-audited PBKDF2/bcrypt/Argon2 implementations.
• **Storing the hash next to the salt with the same hash on every login, an attacker who reads the hash and salt only needs to crack one password at a time, but if you reuse a single global salt across all users, a single rainbow table breaks them all. Each user gets a fresh random salt.

Alternative tools and libraries

The browser hash generator is the fastest path for one-off hashes. For repeated use or scripts, command-line and language libraries take over.

For passwords, treat the language ecosystem differently: use bcrypt, argon2-cffi, passlib, or your platform's recommended adapter, never a hand-rolled SHA loop.

Privacy and the hash generator

The hash generator runs entirely in your browser. The text you type is hashed in memory with the Web Crypto SubtleCrypto interface, and any file you select is streamed through the FileReader API without an upload. There is no log of which inputs were hashed, no analytics on which algorithms are popular, and no way for anyone to reconstruct what you were verifying. Hashes themselves often summarise sensitive material, passwords, internal documents, private keys, exactly the kind of data you should never paste into a stranger's web form. Doing the work client-side keeps the input on your machine, where it belongs. For a task as routine as generating a checksum, the privacy default should be: nothing leaves the page, nothing is stored, nothing is shared.