MD5 vs SHA-256 checksums

What a digest can prove

A cryptographic hash maps input bytes to a fixed-size digest. If you hash the same bytes again and get the same digest, you have evidence that the bytes match the value you expected. That is useful for detecting an interrupted download, a damaged archive, or an accidental change in a build artifact.

A published digest does not prove who published it. An attacker who can replace both a file and its plain checksum can calculate a new matching checksum. Integrity and authenticity need different trust mechanisms: a checksum can be distributed through a trusted channel, while a digital signature or a keyed MAC can bind a value to a key that the verifier already trusts. Collision resistance is also a specific property. A collision means finding two different inputs with the same digest; it is not the same as finding an input for an arbitrary digest.

TheDevTab's Hash Generator hashes text or file bytes in your browser and can show lowercase hex, uppercase hex, or Base64 output. Nothing is uploaded. Keep the exact bytes, encoding, and output format in the process documentation so another system computes the same value.

MD5 and SHA-1 have a narrow remaining use

MD5 and SHA-1 should not be selected for collision-resistant security design. Practical collision attacks have existed for both algorithms, and chosen-prefix collision techniques make maliciously crafted pairs especially relevant to certificates, signed documents, and other adversarial workflows. Do not use either algorithm to create a new signature format, identify a trusted release, or decide whether an attacker altered a file when the expected digest can be replaced with it.

That warning does not mean every old checksum is useless. In a non-adversarial integrity check, MD5 or SHA-1 can still detect many accidental transmission and storage errors, particularly when the algorithm is required by a legacy protocol and the checksum is not the trust anchor. They are also useful when reproducing an older system's output. Document the limitation and do not let a compatibility choice spread into authentication or signature code.

The practical question is whether someone can choose or modify both the content and the checksum. If the answer is yes, a plain MD5 or SHA-1 comparison is not a security boundary. If the checksum comes from a separate trusted channel and the threat is accidental corruption, its collision weakness may not be the relevant failure mode.

Choose SHA-256 or SHA-512 for new checks

SHA-256 and SHA-512 are members of the SHA-2 family and remain standard choices for general integrity and fingerprinting. SHA-256 produces a 256-bit digest and is widely available in APIs, package tools, and file distribution systems. SHA-512 produces a 512-bit digest and can be a good choice when a protocol already specifies it, when a longer digest is useful, or when the platform's 64-bit implementation makes it a suitable fit. SHA-384 is another SHA-2 option with a shorter output than SHA-512.

Pick the algorithm required by the receiving protocol rather than comparing digest strings by length. Hex uses two characters per byte, while Base64 is a more compact representation of the same digest bytes. Uppercase and lowercase hex represent the same value, but a text comparison is case-sensitive unless the process normalizes it. Never silently hash a different text encoding, line ending, or trailing newline and then diagnose the result as an algorithm error.

The Hash Generator displays MD5, SHA-1, SHA-256, SHA-384, and SHA-512 together in normal hash mode. It also accepts files, which avoids turning binary data into a text approximation. Use the digest as a comparison value, not as a secret or a replacement for a release-signing system.

HMAC adds a secret key

HMAC combines a message with a secret key using a defined construction based on a hash. A verifier that knows the same secret can recompute the HMAC and compare it, so an attacker who can read or alter the message cannot create a valid tag without the key. HMAC provides message integrity and authentication between parties that share the key. It does not provide non-repudiation, because either party holding the key could have created the tag.

Do not substitute a plain hash of a secret for HMAC. Expressions such as hash(secret + message) have ambiguous composition and do not provide the security properties of the standardized construction. Some hash designs also make naive prefix-MAC constructions vulnerable to length-extension attacks. A protocol should specify HMAC, the exact hash, key handling, tag encoding, and comparison behavior instead of inventing a formula.

TheDevTab's Hash Generator supports HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. It rejects an empty HMAC key and does not offer HMAC-MD5. Treat a key pasted into a shared session as exposed even when the computation itself stays local.

Keep password hashing separate

None of MD5, SHA-1, SHA-256, or SHA-512 is a password hashing function. General-purpose hashes are designed to be fast, which helps an attacker test large dictionaries or brute-force guesses. Hashing a password once, hashing it repeatedly with a plain digest, or appending a predictable salt does not turn a checksum into password storage.

Password storage needs a dedicated, adaptive password hashing scheme with a unique salt and parameters chosen for the deployment. Argon2id is a strong modern default; scrypt and bcrypt are established alternatives when the platform or existing database requires them. Store the algorithm parameters with the verifier's record and plan a migration path as hardware changes.

A UUID is different again: it is an identifier, not a digest or password verifier. Use TheDevTab's UUID Generator for test identifiers, and use a purpose-built secret generator for credentials. Select a checksum, HMAC, signature, or password hash according to the property the application must enforce.