How Hash Functions Work (MD5, SHA-256, and More)

A hash function maps arbitrary-length data to a fixed-size output. Cryptographic hashes add security goals:

• Pre-image resistance — given a digest, it should be infeasible to find an input that produces it
• Second pre-image resistance — given one input, it should be hard to find a different input with the same digest
• Collision resistance — it should be hard to find any two different inputs that share a digest

Fixed length outputs (common sizes)

• MD5 — 128 bits (32 hex characters)
• SHA-1 — 160 bits (40 hex)
• SHA-256 — 256 bits (64 hex)
• SHA-512 — 512 bits (128 hex)

Same algorithm + same input → same digest every time (deterministic). That is how download pages can publish “SHA-256 of this installer is …” and you can recompute it locally to check the file was not corrupted or swapped.

Generate a sample digest in the free hash generator, then change one letter of the input and hash again — the avalanche effect should scramble the output.

Encryption is designed to be reversed with a key. Hashing is designed not to be reversed. If you can “get the original back” from a hash alone, something is wrong with your threat model or you are not using a cryptographic hash.

Concept	Reversible?	Primary job
Encryption (AES, etc.)	Yes, with key	Confidentiality
Encoding (Base64, hex)	Yes, always	Representation / transport
Hashing (SHA-256, etc.)	No (one-way)	Integrity / fingerprints

Base64 confusion

Base64 output looks random to humans, so people call it “encrypted.” It is encoding only — anyone can decode it. Read our Base64 guide and try the Base64 encoder decoder for round-trips. Hashes do not round-trip.

What about “decrypt MD5” websites?

Those sites are not reversing the math. They look up digests in huge tables of previously seen inputs (rainbow tables / breach corpora). Short, common passwords get “recovered.” Long random secrets do not. That is why password storage needs slow, salted password hashes (bcrypt, Argon2, etc.), not a single raw MD5 of the password.

Algorithm choice is about collision resistance and modern recommendations — not which logo looks cooler on a tool page.

• MD5 — broken for collision resistance. Real-world collision attacks exist. Do not use MD5 for security signatures, certificates, or anything adversarial. Still appears in legacy checksums and non-security fingerprints.
• SHA-1 — also broken for collisions (practical attacks demonstrated). Browsers and CAs retired SHA-1 certificates years ago. Avoid for new security designs.
• SHA-256 — current default workhorse for integrity, git-like content addressing, and many protocols. 256-bit digest, widely available (including Web Crypto in browsers).
• SHA-512 — larger digest; fine and sometimes preferred on 64-bit systems. Not “twice as secure as 256” in a simple linear sense, but more output bits for fingerprint space.

Practical rule

For new integrity checks and general-purpose digests, prefer SHA-256 (or SHA-512). Use MD5/SHA-1 only when a legacy system forces you to match an existing checksum format — and never for password storage or anti-forgery by itself.

Compare algorithms on the same input with the free hash generator multi-algorithm view so you see length and value differences side by side.

Integrity means “did this data change?” not “who is allowed to read it?”

Typical flow

1. Publisher computes SHA-256 of a file and posts the hex digest on HTTPS.
2. You download the file from any mirror.
3. You compute SHA-256 locally and compare every character of the hex string.
4. Match → contents match what the publisher hashed. Mismatch → corruption or wrong file.

A matching hash does not prove the publisher is honest. If an attacker controls both the file and the published digest, both will match. Trust the channel where you got the expected digest (official site, signed release, package manager metadata).

Verification in tools

Many hash tools include “compare two hashes” so you paste the expected value and the computed value without eyeballing 64 hex characters. One differing nibble is enough to fail the check.

Related identifiers

UUIDs identify records; they are not content hashes. For unique IDs, see the free UUID generator and our UUID guide. Hashes fingerprint bytes; UUIDs label entities.

Systems should store password verifiers, not passwords. On signup they hash the password (with salt and a slow algorithm); on login they hash the attempt and compare digests.

What not to do

• Store plaintext passwords
• Store a single MD5(password) or SHA-256(password) without salt and without a password-specific KDF
• Hash in the browser and send only the hash if the server treats that hash as the password (the hash becomes the password)

What to do (application design)

Use established password hashing functions (Argon2, bcrypt, scrypt, PBKDF2 with solid parameters), unique salts, and constant-time comparison. That is server-side security engineering — a one-click hash generator is for learning and integrity demos, not a full auth stack.

For user-facing strength checks while you pick a passphrase, use the free password strength checker and our password strength guide. To create a high-entropy secret, use a password generator and the related password generator guide.

Prefer client-side tools for anything sensitive. Paste or type input, pick algorithms, copy digests, and optionally verify against a known value.

1. Open the free hash generator.
2. Paste the text (or sample string) you want to fingerprint.
3. Select MD5, SHA-1, SHA-256, and/or SHA-512 depending on your need.
4. Copy the hex digest you need (usually SHA-256 for modern checks).
5. If verifying, paste the expected hash into the comparison field and confirm a match.
6. Toggle upper/lowercase hex only if a consumer expects a specific case (values are the same bits).
7. For secrets, confirm the page hashes locally and clear the field when finished.

Client-side matters

Browser Web Crypto (for SHA algorithms) and local MD5 implementations can run without uploading your string. Still avoid pasting production passwords or private keys into any third-party site you do not trust — including “just testing.” Use dummy data for demos.

Most failures are category errors.

• Using MD5/SHA-1 for security — fine for accidental corruption checks in legacy systems; wrong for anti-tamper against attackers
• Confusing hash with encryption — you cannot “unlock” a digest with a password to recover a document
• Truncating digests carelessly — shortening SHA-256 for shorter URLs reduces collision resistance; know the tradeoff
• Comparing hashes with normal string inequality in security code — use constant-time compare for auth-related checks
• Hashing already-encoded forms inconsistently — hashing Base64 text vs raw bytes yields different digests; document the canonical form
• Assuming identical hex means identical meaning across algorithms — MD5 of X and SHA-256 of X are unrelated strings

This guide is educational, not a penetration-test report or compliance checklist. Production systems need full threat modeling and maintained libraries.