Hash Generator MD5 · SHA-1 · SHA-256 · SHA-512

What is a hash?

A hash is a short, fixed-length fingerprint calculated from data of any size. Feed a hash function a single letter or a four-gigabyte disk image and SHA-256 returns exactly 256 bits either way, written as 64 hexadecimal characters. The same input always produces the same output, which is what makes hashes useful as identifiers and integrity checks.

The property that makes a hash function cryptographic rather than merely a checksum is that it is hard to work backwards or to engineer matches. Three separate guarantees matter. Preimage resistance means that given a digest you cannot find an input that produces it. Second-preimage resistance means that given one input you cannot find a different input with the same digest. Collision resistance means you cannot find any two distinct inputs that collide, even if you get to choose both. MD5 and SHA-1 still hold up reasonably well for the first two but have lost the third completely, which is exactly why they are marked legacy in the tool above.

The other characteristic worth seeing for yourself is the avalanche effect. Hash the word hello, then hash hellp. A single changed letter does not produce a slightly different digest — roughly half the output bits flip, and the two results look completely unrelated. That is what makes a hash a reliable tripwire for accidental corruption.

What is a hash generator?

A hash generator is a tool that runs one or more hash functions over the input you supply and shows you the resulting digests. That is the whole job — but in practice you also need to compare a digest against a published value, copy it somewhere, or produce several algorithms at once because different projects publish different checksums.

The generator on this page handles text and local files, calculates all four algorithms side by side, converts between lowercase and uppercase hexadecimal, and includes a verification box on every result so you can paste in an expected value and get a plain yes or no. Because everything runs as JavaScript inside your own browser tab, there is no upload step and no server that ever sees your data.

How hash functions work

MD5, SHA-1, SHA-256 and SHA-512 all share the same overall shape, known as the Merkle–Damgård construction. The input is first padded so its length is an exact multiple of the block size — 512 bits for MD5, SHA-1 and SHA-256, and 1024 bits for SHA-512. Part of that padding encodes the original message length, which prevents two different messages from padding into the same byte sequence.

The algorithm then starts from a fixed initial state and processes one block at a time. For each block it runs a compression function: dozens of rounds of additions, bitwise operations and rotations that thoroughly mix the block into the running state. MD5 uses 64 rounds over 32-bit words, SHA-1 uses 80, SHA-256 uses 64, and SHA-512 uses 80 rounds over 64-bit words. When the last block has been absorbed, the final state is written out as the digest.

A consequence of this design worth knowing is the length extension attack. Because the digest is the internal state, someone who knows hash(secret + message) and the length of the secret can compute hash(secret + message + padding + extra) without knowing the secret at all. This is why you must never build a message authentication code by concatenating a secret with data and hashing it. Use HMAC, which is specifically constructed to resist this.

MD5 explained

MD5 — Message Digest algorithm 5 — was designed by Ron Rivest in 1991 and published as RFC 1321 in 1992. It produces a 128-bit digest, written as 32 hexadecimal characters, and it is fast: hashing hundreds of megabytes per second on ordinary hardware is routine.

Its cryptographic life ended early. Theoretical weaknesses appeared in the mid-1990s, and in 2004 a team led by Xiaoyun Wang demonstrated real collisions. Today, producing two different files with the same MD5 digest takes seconds on a laptop, and chosen-prefix collisions — where an attacker controls how both files begin — are practical too. The Flame malware discovered in 2012 used an MD5 collision to forge a code-signing certificate, which is the clearest possible demonstration of why the algorithm cannot secure anything an adversary can influence.

MD5 has not disappeared, though, because a collision is not the same as corruption detection. Plenty of package mirrors, older backup systems and internal tools still publish MD5 sums, and for spotting a truncated download or a flipped bit on disk MD5 works fine. Use it to match a checksum someone else already published — not to secure anything new.

SHA-1 explained

SHA-1 was published by NIST in 1995 as a corrected version of the short-lived SHA-0. It produces a 160-bit digest, written as 40 hexadecimal characters, and for well over a decade it was the default hash of the internet, underpinning TLS certificates, code signing and Git.

NIST formally deprecated SHA-1 for digital signatures in 2011, and browsers stopped trusting SHA-1 certificates in early 2017 — the same year that Google and CWI Amsterdam published SHAttered, the first practical SHA-1 collision, presented as two different PDF files with identical digests. In 2020 Gaëtan Leurent and Thomas Peyrin demonstrated a chosen-prefix collision for roughly the cost of tens of thousands of dollars in rented compute, and NIST has since set out a full retirement of SHA-1 by the end of 2030.

You will still meet SHA-1 in the wild. Git uses it for object identifiers, though the project has been adding SHA-256 support, and Git additionally applies collision detection to the inputs it hashes. HMAC-SHA-1 also remains unbroken as a message authentication construction, because HMAC does not rely on collision resistance. For anything new, however, choose SHA-256.

SHA-256 explained

SHA-256 belongs to the SHA-2 family, published by NIST in 2001 and standardised in FIPS 180-4. It produces a 256-bit digest, written as 64 hexadecimal characters, by running 64 rounds of compression over 32-bit words.

No practical attack against SHA-256's collision or preimage resistance exists. Finding a collision by brute force would take roughly 2¹²⁸ operations thanks to the birthday bound, which is far beyond any conceivable computing capability. That security margin, plus twenty-plus years of scrutiny, is why SHA-256 is the default almost everywhere: TLS certificates, code signing, Linux distribution checksums, Bitcoin, container image digests and package manager lock files.

Modern processors also help. Intel and AMD chips with the SHA-NI extensions, and ARMv8 chips with cryptographic extensions, execute SHA-256 rounds in hardware, which makes it extremely fast in real deployments. If you are choosing an algorithm and have no specific constraint, SHA-256 is the correct answer.

SHA-512 explained

SHA-512 is SHA-256's larger sibling in the SHA-2 family. It produces a 512-bit digest, written as 128 hexadecimal characters, and internally works with 64-bit words across 80 rounds and 1024-bit blocks.

In pure software on a 64-bit CPU, SHA-512 is often faster than SHA-256 despite producing twice as much output, because it moves twice as much data per operation. That advantage disappears on hardware with SHA-256 acceleration, and on 32-bit platforms SHA-512 is noticeably slower. Both algorithms are considered equally secure in practice; the longer digest buys margin rather than solving a known weakness.

SHA-512 is a good choice when a specification calls for it, when you want extra headroom for long-lived archival fingerprints, or when you are hashing large volumes in software on 64-bit servers. It is also the basis for SHA-384 and SHA-512/256, truncated variants that are immune to the length extension issue described earlier.

MD5 vs SHA-1 vs SHA-256 vs SHA-512

The practical differences come down to digest length, collision resistance and what the ecosystem around you expects.

• Digest length. 128, 160, 256 and 512 bits respectively — 32, 40, 64 and 128 hexadecimal characters. Length is the quickest way to guess which algorithm produced an unlabelled checksum, though it never proves it.
• Collision resistance. MD5 and SHA-1 are broken; SHA-256 and SHA-512 are not. If an attacker could ever choose or influence the data being hashed, only the SHA-2 options are acceptable.
• Speed. MD5 is the fastest, then SHA-1. Between the SHA-2 options it depends on your hardware, as described above. For file verification the difference rarely matters, since disk read speed dominates.
• Ecosystem. SHA-256 is what most projects publish today. MD5 and SHA-1 mostly survive as legacy checksums you need to match rather than choices you make.

A short decision rule: if you are verifying against a published checksum, use whatever algorithm the publisher used. If you are choosing for yourself, use SHA-256. If a standard or policy tells you to use SHA-512, use SHA-512. Never pick MD5 or SHA-1 for something new that has a security requirement.

Hashing vs encryption

Encryption is a two-way transformation controlled by a key: encrypt with the key and you get ciphertext, decrypt with the right key and you get the original back, byte for byte. Its purpose is confidentiality.

Hashing has no key and no inverse. Information is deliberately discarded — a four-gigabyte file collapses into 32 bytes — so there is no procedure, no matter how clever, that recovers the input from the digest. Its purpose is integrity and identity.

This is why the phrase "decrypt an MD5 hash" describes something that does not exist. Sites claiming to reverse hashes are running dictionary lookups: they precomputed the hashes of billions of common passwords and words, and they search that table. If your input is a common word, they find it. If your input is an actual file, they never will. Salting exists precisely to defeat that precomputation for password storage.

File checksums and integrity verification

A checksum is any short value derived from data and used to detect change. Simple checksums such as CRC32 or Adler-32 are excellent at catching accidental corruption and extremely cheap to compute, but they are trivial to forge deliberately. Cryptographic hashes cost more to compute and additionally resist an attacker who wants two files to match.

That distinction determines which you need. Detecting a bad disk sector or an interrupted transfer is an accident problem, and any checksum works. Confirming that the installer you downloaded is the one the developer built, over a network you do not fully control, is an adversary problem — that needs SHA-256.

Worth remembering: a checksum published on the same page as the download only protects against corruption in transit. If an attacker can modify the download, they can usually modify the checksum next to it. Real supply-chain protection comes from a signature over the checksum file, verified against a key you obtained separately.

How to verify a download using SHA-256

1. Find the published checksum on the project's download or releases page. It is usually a SHA256SUMS file or a value shown beside the link.
2. Open the File tab above and drop in the file you downloaded.
3. Make sure SHA-256 is ticked, then press Generate hashes.
4. Press Verify on the SHA-256 result card and paste the published checksum into the box.
5. A green Match means the bytes on your disk are identical to what the publisher hashed. A red result means they are not — delete the file and download it again from the official source.

If you paste a whole line from a SHA256SUMS file, such as e3b0c442… ubuntu.iso, the tool notices and offers to keep just the hash rather than silently discarding part of what you pasted.

How to compare two hashes

Never compare digests by eye. Two SHA-512 values differing in one character in the middle look identical at a glance, and that is exactly the failure mode an attacker relies on. Paste both into the compare panel and let the tool check every character.

Two rules the comparison follows. Letter case is ignored, because hexadecimal FF and ff are the same byte — many tools output uppercase and many publish lowercase. Everything else is strict: spaces or stray characters inside the value produce a validation error rather than being quietly stripped, because silently ignoring characters is how a wrong comparison ends up looking correct.

Text hashing

Text has to become bytes before it can be hashed, and the encoding you choose changes the result. This tool always uses UTF-8, which is the default nearly everywhere. The same string encoded as UTF-16 would produce a completely different digest.

Everything you type is hashed exactly as entered. Leading and trailing spaces count. Tabs count. A trailing newline counts — this is the single most common reason a hash calculated in a browser does not match one calculated with echo "text" | sha256sum, since echo appends a newline byte unless you pass -n.

Line endings matter for the same reason. A Unix line break is one byte, 0x0A, while a Windows line break is two, 0x0D 0x0A. The visible text looks identical but the bytes differ, so the hashes differ. There is one browser behaviour to know about here: the HTML specification requires a text box to report its value with line breaks normalised to LF, so a CRLF sequence you paste into the box above is already LF by the time any JavaScript can read it. That is a property of every text area on the web, not a transformation this tool applies. When you need the byte-exact digest of a file that genuinely contains CRLF, hash the file itself on the File tab, where the raw bytes are read straight from disk.

Unicode works throughout — Hindi, Arabic, Chinese, accented Latin text and emoji all encode correctly as UTF-8. One subtlety: visually identical text can have different Unicode representations. An é written as a single code point and the same letter written as e plus a combining accent are different byte sequences and hash differently. That is correct behaviour, not a bug, and it is why normalisation is a deliberate step you would apply before hashing rather than something a hash tool should do behind your back.

File hashing

Files are hashed as raw bytes. This matters more than it sounds: a tool that read a file as text and re-encoded it would corrupt binary data and produce a checksum that matches nothing. Images, executables, ISO files, archives and PDFs all hash correctly here because the bytes are passed through untouched.

Reading happens in four-megabyte chunks so the interface stays responsive and progress can be reported while a large file is processed. MD5 is computed incrementally as those chunks arrive. SHA algorithms are handed to the browser's Web Crypto implementation, which needs the complete input at once, so a SHA hash of a very large file is limited by how much memory your device can allocate rather than by any limit imposed here.

Files above roughly 100 MB show an advisory that hashing may take a moment. Nothing is rejected on size alone; if the browser genuinely cannot allocate enough memory you get a clear message suggesting MD5 only, which streams and does not need the whole file at once.

Hashing and password security

Passwords are the one application where a general-purpose hash function is the wrong tool, and the reason is speed. Every property that makes SHA-256 excellent for checksums — blazing throughput, no memory requirements, hardware acceleration — helps an attacker who has stolen your database far more than it helps you. A single modern GPU tests billions of candidate passwords per second against unsalted fast hashes.

Password hashing functions invert those properties deliberately. Argon2, which won the Password Hashing Competition in 2015, is memory-hard: it forces the attacker to allocate a configurable amount of RAM per guess, which is exactly what GPUs and ASICs are bad at. bcrypt has a tunable cost factor and has held up well since 1999. scrypt is likewise memory-hard. PBKDF2 is the weakest of the four but is still acceptable where a certified implementation is required.

All of them salt each password with unique random data, so two users with the same password get different stored values and precomputed rainbow tables become useless. All of them let you raise the cost as hardware improves. If you are storing passwords, use a well-maintained library implementation of one of these — not MD5, not SHA-1, and not SHA-256 either.

Why MD5 is not secure for passwords

Beyond being broken for collisions, MD5 is simply too fast. Consumer graphics hardware reaches tens of billions of MD5 computations per second, so any password from a wordlist or a common pattern falls almost immediately. MD5 also has no built-in salting, so identical passwords produce identical hashes and one lookup table cracks them all at once.

Why SHA-1 is deprecated for security

SHA-1's collision weakness rules it out for signatures and certificates, and its speed rules it out for passwords for the same reason as MD5. Standards bodies and browser vendors removed trust in SHA-1 signatures years ago, and NIST has scheduled its complete retirement. Keep it available for reading legacy data; do not build on it.

When to use SHA-256

Use SHA-256 as your default. It is the algorithm most release checksums, container registries, package managers and signing systems already use, so choosing it means the value you calculate is directly comparable with what everyone else publishes. It has a large security margin, is widely hardware-accelerated, and its 64-character digest is short enough to paste into a ticket or commit message without pain.

When to use SHA-512

Choose SHA-512 when a specification or internal policy requires it, when you want the longest practical fingerprint for archival records, or when you are hashing very large volumes in software on 64-bit machines that lack SHA-256 acceleration. It is not more secure in any way that matters against realistic threats — both are unbroken — so treat it as a fit-for-requirement choice rather than an upgrade.

Browser-based hashing and privacy

This tool has no backend. Text you type and files you select are read into your browser's memory and hashed there using JavaScript and the Web Crypto API. Nothing is sent over the network, so there is no server log, no temporary upload directory and no retention policy to trust.

That is not a small detail. The files people most often want to checksum — key material, signed documents, database dumps, disk images — are exactly the files that should never be uploaded to a stranger's server just to compute 64 characters of hexadecimal.

You can confirm this yourself in two ways. Open your browser's developer tools, switch to the Network tab, and hash a file: no request is made as a result of hashing, and nothing carrying your text or file contents is ever sent. (Like every page on this site, the page itself may load ToolAdda's analytics script — that is page-level analytics and it never receives your input.) The stronger test is simpler still: disconnect from the internet entirely once the page has loaded, then hash anything you like. It all keeps working, because there is nothing to talk to.

Local history is off unless you switch it on, and even then only digests, timestamps and a label are written to this browser's local storage — never the text you hashed or the contents of a file. Clearing it removes the entry immediately.

Common hashing mistakes

• Hashing a trailing newline by accident. echo "abc" sends four bytes, not three. Use echo -n or printf when you want to match a hash of the bare string.
• Comparing digests visually. Always paste both values into a comparison tool. Eyes skip characters, especially in the middle of a 128-character SHA-512 value.
• Assuming length identifies the algorithm. A 64-character hex string is probably SHA-256, but it could equally be SHA-512/256 or something truncated. Length narrows the field; it does not prove anything.
• Trusting a checksum from the same place as the file. If an attacker controls the download page, they control both. You need a signature verified with an independently obtained key.
• Building a MAC as hash(secret + data). This is vulnerable to length extension. Use HMAC instead.
• Using a plain hash for passwords. Covered above — use Argon2, bcrypt or scrypt.
• Ignoring line-ending differences. A file checked out with CRLF on Windows will not match a checksum generated on Linux with LF.
• Mixing up encodings. The same string in UTF-8 and UTF-16 produces different digests. Agree on the encoding before comparing.
• Treating MD5 as if it were secure. It is fine as a corruption check and useless against an adversary. Know which situation you are in.

Frequently asked questions