Generate a SHA-256, MD5, SHA-1, SHA-512 or SHA-3 digest from any text, or paste a published checksum and verify it. All eight algorithms side by side.
Hashed exactly as typed: a trailing space, a capital letter or a line break changes the digest completely.
Enter text above and every algorithm fills in at once.
| Algorithm | Bits | Digest |
|---|---|---|
| MD5 | 128 | — |
| SHA-1 | 160 | — |
| SHA-256 | 256 | — |
| SHA-384 | 384 | — |
| SHA-512 | 512 | — |
| SHA3-256 | 256 | — |
| SHA3-384 | 384 | — |
| SHA3-512 | 512 | — |
Block size is the compression-function block for MD5 and the SHA-1/SHA-2 families, and the sponge rate for SHA-3. Sources: RFC 1321, FIPS 180-4 and FIPS 202.
| Algorithm | Standard | Construction | Block or rate | Status |
|---|---|---|---|---|
| MD5 | RFC 1321 | Merkle–Damgård | 512 | Broken since 2004 |
| SHA-1 | FIPS 180-4 | Merkle–Damgård | 512 | Broken since 2017 |
| SHA-256 | FIPS 180-4 | Merkle–Damgård | 512 | No published collision |
| SHA-384 | FIPS 180-4 | Merkle–Damgård | 1,024 | No published collision |
| SHA-512 | FIPS 180-4 | Merkle–Damgård | 1,024 | No published collision |
| SHA3-256 | FIPS 202 | Sponge | 1,088 | No published collision |
| SHA3-384 | FIPS 202 | Sponge | 832 | No published collision |
| SHA3-512 | FIPS 202 | Sponge | 576 | No published collision |
You might also find these calculators useful
See which AES, RSA, ECC and hash key sizes are equally strong.
Guess resistance, crack time and NIST 800-63B rev 4 checks
Text to binary, hex, decimal or octal — and back, in real UTF-8
Generate UUID v4, v6, v7, ULID and NanoID in bulk — or decode one.
Paste any text and this page returns its MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384 and SHA3-512 digests together, in hexadecimal or Base64. Switch to Verify and it compares your text against a checksum you paste — the actual reason most people hash anything. Everything runs in your browser; the text never leaves your machine.
A hash function turns an input of any length into a fixed-length value called a digest, and the same input always produces the same digest. Three properties make one cryptographic: it is one-way, so the input cannot be recovered from the digest; it is collision-resistant, so no two inputs should share a digest; and it has the avalanche property, so changing a single bit of input changes roughly half the output bits. SHA-256 returns 256 bits, written as 64 hexadecimal characters, whether you feed it one letter or a gigabyte. That fixed size is what makes a digest useful as a fingerprint: you can compare two digests in a glance where comparing two files would take a transfer.
The shape of every hash
You download an installer, the project publishes a SHA-256 line, and Verify tells you whether they agree before you run anything.
A developer digests a JSON body to Base64 for a signature header and checks the value byte-for-byte against what the server computed.
Hash a config file on two machines and compare the digests instead of diffing across a slow link or an air gap.
An old release only ever published an MD5. You can still check it for accidental corruption while knowing, from the warning on screen, that it proves nothing against tampering.
Comparing SHA-1 against SHA-256 and SHA3-256 on real input shows the digest length change a database column or protocol field has to absorb.
Hash a sentence, change one letter, and watch the digest change entirely — the fastest way to understand why near-matches do not exist.
A publisher prints the digest of a release; you hash your download and compare. If a mirror served you a modified file, the digests differ. It is the one integrity check that needs no trust in the network, only in the published value.
Backup tools, caches and sync clients compare digests instead of contents. Two files with the same SHA-256 are treated as the same file, so a system can skip transferring, storing or re-indexing them.
Signing algorithms operate on a fixed-size digest, not the megabytes behind it. That is why a broken hash breaks the signature scheme above it: SHAttered produced two PDFs with one SHA-1 digest, so one signature covered both.
Git names every commit, tree and blob by its digest; container registries and IPFS do the same. The identifier is derived from the content, so a changed byte produces a different address rather than silently overwriting one.
CRC-32 and Adler-32 catch accidental corruption cheaply and can be forged deliberately in moments. Use them for transmission errors; use SHA-256 or SHA-3 when someone might want the digest to collide.
MD5 lost collision resistance in 2004 and SHA-1 in 2017. Knowing which standard defines an algorithm and when it was broken is the difference between a legacy checksum and a live vulnerability.
A hash function converts an input of any length into a fixed-length digest, deterministically: the same input always gives the same result. A cryptographic hash adds three guarantees — you cannot work backwards from the digest to the input, you cannot find two inputs with the same digest, and changing one bit of input changes about half the output bits. SHA-256 always returns 256 bits regardless of whether the input is a word or a film.
No, and nothing can — hashing is not encryption and has no key. A digest throws information away: unlimited inputs map to a fixed number of outputs, so the original cannot be recovered even in principle. Sites advertising “MD5 decrypt” are looking your digest up in a table of previously computed hashes, which works only for inputs somebody already hashed, such as common passwords and short strings.
No. NIST SP 800-63B states that passwords “SHALL be salted and hashed using a suitable password hashing scheme”, and names the schemes in SP 800-132 — PBKDF2, bcrypt, scrypt or Argon2 — with a cost factor set as high as your verifier can bear. SHA-256 and SHA-512 are fast by design, which is exactly the property a password store must not have: a modern GPU tries billions of plain SHA-256 guesses per second.
Not for anything security-related. MD5 collisions were published in 2004 and now take seconds on ordinary hardware, so an attacker can produce two different files with the same MD5. It remains acceptable as a cheap check against accidental corruption — a truncated download, a flipped bit — where nobody is trying to fool you. Anywhere an adversary could influence the input, use SHA-256 or SHA-3.
Both come from FIPS 180-4 and differ in digest size and internal word width. SHA-256 produces 256 bits from 32-bit words over 512-bit blocks; SHA-512 produces 512 bits from 64-bit words over 1,024-bit blocks, which makes it faster than SHA-256 on 64-bit processors despite the longer output. Both are unbroken; pick SHA-256 unless you specifically want the larger margin or the speed on 64-bit hardware.
SHA-3 is the family standardised in FIPS 202 in 2015, built on the Keccak sponge construction rather than the Merkle–Damgård design behind MD5, SHA-1 and SHA-2. It exists as a structurally different backup, not because SHA-2 is weak — SHA-2 remains unbroken and is still the default almost everywhere. Choose SHA-3 when you want a design that does not share SHA-2's lineage, or when a specification asks for it.
That is the avalanche effect, and it is a deliberate design requirement. A secure hash aims to flip roughly half the output bits for any single-bit change in the input, so digests reveal nothing about how similar two inputs are. It is also why there is no such thing as a near-match: the Verify mode above reports where two digests first differ, but that position carries no information about how close the inputs were.
Run the publisher's algorithm over the file and compare digests character by character. On macOS or Linux that is shasum -a 256 file, and on Windows CertUtil -hashfile file SHA256. Then paste the published value and yours into Verify above, which compares them and reports the first differing character. Crucially, the published checksum must come from a source you trust — a checksum hosted beside a tampered download proves nothing.
No. Encryption is reversible with a key and is designed to protect confidentiality; hashing is one-way, keyless, and designed to detect change. “Encrypt with MD5” is a category error you will see in old tutorials — MD5 has no key and produces nothing you can decrypt. If you need to get data back, you need encryption, not a digest.
A collision is two different inputs producing the same digest. Collisions must exist because a hash maps unlimited inputs onto a fixed number of outputs; the security question is whether anyone can find one. The generic cost is about 2^128 operations for a 256-bit digest — the birthday bound — but MD5 and SHA-1 have published attacks far cheaper than that, which is why this page reports the year each was broken instead of a bound that no longer holds.
Both encode identical bytes at different densities. Hexadecimal spends two characters per byte; Base64 spends four characters per three bytes and pads the result to a multiple of four. A SHA-256 digest is 32 bytes, so it is 64 hexadecimal characters or 44 Base64 characters, the last of which is padding. Verify above accepts either spelling and compares in whichever format you pasted.
Yes, every one of them. Hashing operates on bytes, so “Hello” and “hello” differ in exactly one byte and produce entirely unrelated digests, and a trailing space or newline copied with a checksum is the most common reason a verification fails. Two of the presets above demonstrate this with the same expected digest and a single capital letter of difference.
A salt is a random value stored alongside a password hash and mixed in before hashing, so that two users with the same password get different stored values and precomputed tables are useless. This page adds nothing: it hashes exactly the bytes you type, which is what you need for checksums and signatures. Salting belongs to password storage, where it is a requirement of a password hashing scheme rather than something bolted onto a plain digest.
SHA-256 for almost everything — it is unbroken, universally supported, and the default in TLS, Git and package managers. Use SHA-512 where you want a larger margin or better throughput on 64-bit CPUs, and SHA3-256 where a specification calls for it or you want a construction unrelated to SHA-2. Use MD5 and SHA-1 only to read checksums that already exist, and never to create new ones.