Hash Generator

Almost nobody arrives at a hash tool knowing which algorithm they need. What you usually have is a bare hex string — pasted into a release page, printed in a vendor email, stored in a database column, quoted in a bug report — and a piece of text you think produced it. The real question is not "give me a SHA-256", it is "which of these algorithms turns my text into that string, if any of them do". So this tool does not ask you to choose. It computes MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA3-256, CRC32 and xxHash64 in one pass and shows all eight side by side, so you can scan for your value instead of guessing and re-running.

The digests are produced by hash-wasm, a WebAssembly implementation, running inside a Web Worker on your own device. Nothing you type is sent anywhere. The browser's built-in crypto.subtle was not used because it cannot do the job: it has no MD5, no CRC32 and no non-cryptographic hashes at all, and those are exactly the algorithms you meet when you are checking a legacy checksum. This tool hashes the text in the input pane — it is not a file hasher, so what you see is the digest of precisely the characters you entered.

The trailing newline is why your checksum does not match

This is the single most common reason two people hash "the same" text and get different answers, and it is worth internalising before you go hunting for a subtler explanation. A hash function has no concept of "meaningful" content. It consumes bytes. One extra byte at the end — 0x0A, a line feed your editor added when you pressed Enter, or that your terminal appended when you piped a string through echo — produces a digest with no visible relationship to the original.

Concretely: the MD5 of abc is 900150983cd24fb0d6963f7d28e17f72, while the MD5 of abc\n is 0bee89b07a248e27c83fc3d5951213c1. There is no partial similarity to warn you that you are one character off. If your value is close but wrong, it is not close — it is wrong for a reason.

Practical consequences worth knowing:

• echo -n "text" hashes what you expect; plain echo "text" appends a newline and does not.
• Most text editors add a final newline on save, so hashing a file and hashing the visible contents pasted here can legitimately differ by exactly that byte.
• Copying from a rendered web page often picks up a trailing space or a non-breaking space (U+00A0) that looks identical to a normal space.
• Windows line endings (\r\n) hash differently from Unix ones (\n). A file that passed through a Windows editor will not match a checksum generated on Linux.

The character and byte counts shown alongside the output are the fastest way to confirm you have what you think you have. If you expected 3 characters and the counter says 4, you have found your problem.

What each of the eight algorithms is actually for

• MD5 — 128 bits. Cryptographically broken; collisions can be produced deliberately in seconds. Still everywhere as a non-adversarial integrity check: package manifests, cache keys, ETags, deduplication. Fine for "did this file arrive intact", useless for "did an attacker tamper with this file".
• SHA-1 — 160 bits. Deprecated for signatures since the 2017 SHAttered collision, but it is still the object identifier inside most Git repositories, so you will keep meeting it.
• SHA-256 — 256 bits. The sensible default for anything new. What TLS certificates, Bitcoin, Linux distribution checksums and virtually every modern signing scheme use.
• SHA-384 — a truncated SHA-512. Turns up mainly in TLS cipher suites and Subresource Integrity attributes.
• SHA-512 — 512 bits, and counter-intuitively faster than SHA-256 on 64-bit hardware because it works on 64-bit words. A reasonable default when output length is not a constraint.
• SHA3-256 — same output size as SHA-256 but a completely different internal construction (Keccak sponge rather than Merkle–Damgård). Standardised as insurance in case a structural weakness is ever found in the SHA-2 family. Note that SHA3-256 and SHA-256 of the same input are entirely unrelated values.
• CRC32 — 32 bits, and not a hash function in the cryptographic sense at all. It is an error-detection code designed to catch transmission noise. Used by ZIP, gzip and PNG. Trivially forgeable, and with only about four billion possible outputs, collisions occur by accident.
• xxHash64 — extremely fast, non-cryptographic. Built for hash tables, checksums over huge datasets and change detection where throughput matters more than resistance to a determined attacker.

If you are trying to identify an unknown digest, its length narrows the field immediately: 8 hex characters means CRC32, 16 means xxHash64, 32 means MD5, 40 means SHA-1, 64 means SHA-256 or SHA3-256, 96 means SHA-384, 128 means SHA-512.

Hashing is one-way, and it is not password storage

A hash cannot be reversed. "Decrypt this MD5" sites are lookup tables of previously computed digests for common strings, not decryption — they work only because the input was guessable. Hashing is not encryption and has no key.

That also means a plain digest is the wrong way to store passwords. General-purpose hashes are designed to be fast, which is precisely what an attacker with a stolen database wants. Password storage needs a deliberately slow, salted, memory-hard function such as bcrypt, scrypt or Argon2id. None of the eight algorithms here are appropriate for that, no matter how many times they are applied.

Where these digests are genuinely the right tool: verifying a download against a published checksum, generating a stable cache key or content-addressed identifier, detecting whether a configuration blob changed between deployments, deduplicating records, and confirming that text survived a copy-paste between two systems intact.