Hash Generator — Free Online Tool

What is Hash Generator (MD5, SHA-1, SHA-256, SHA-384, SHA-512, CRC-16)?

A hash generator condenses any amount of text into a short, fixed-length fingerprint that changes completely if a single bit of the input changes. This tool computes six of those fingerprints at the same time — MD5, SHA-1, SHA-256, SHA-384, SHA-512 and CRC-16 — from one input box, so you can compare algorithms side by side without re-running anything.

• Six digests from one input: Type once and every row updates: MD5 (128-bit), SHA-1 (160-bit), SHA-256, SHA-384 and SHA-512 from the SHA-2 family defined in FIPS 180-4, plus a CRC-16 checksum. Each row has its own Copy button, so you can lift just the digest you need.
• Text in, UTF-8 bytes out: The input is encoded as UTF-8 before hashing, exactly the way TextEncoder does it. That matters for non-ASCII text: "Grüße" is seven bytes in UTF-8 and five in ISO-8859-1, and the two produce completely different digests.
• Lowercase hex, fixed width: Every byte is rendered as two lowercase hex characters with zero padding, so digests are always 32, 40, 64, 96 and 128 characters wide respectively. CRC-16 is shown as four hex characters.
• Two very different kinds of function: MD5 and the SHA family are cryptographic hash functions with avalanche behaviour and (for SHA-2) collision resistance. CRC-16 is a cyclic redundancy check built to catch transmission noise — it is fast, tiny and trivially forgeable, and it is included for protocol and firmware work, not for security.
• Nothing is uploaded: SHA digests come from the browser's built-in Web Crypto API (crypto.subtle.digest); MD5 and CRC-16 are computed by bundled JavaScript because Web Crypto deliberately does not expose MD5. Either way the text never leaves the tab.

Why use the Hash Generator?

Hashes let you compare, index and verify data without keeping or transmitting the data itself, and seeing several algorithms at once tells you which one a system is actually using.

• Identify the algorithm from the length: When you inherit a digest with no documentation, its width is the clue: 32 hex characters is MD5, 40 is SHA-1, 64 is SHA-256, 96 is SHA-384 and 128 is SHA-512. Hashing a known sample here and matching the width — then the value — settles the question in seconds.
• Reproduce a digest a system rejected: Integration bugs are usually encoding bugs. Hashing the exact string you think you sent, then comparing against the digest the other side computed, isolates whether the mismatch is trailing whitespace, a newline, BOM, or a charset difference rather than a broken algorithm.
• Deduplicate and cache-key without storing content: A SHA-256 digest is a stable 64-character key for a blob of text, so you can spot duplicate records, build cache keys, or fingerprint config files without keeping a second copy of the content.
• See avalanche behaviour for yourself: Changing one character rewrites roughly half the output bits. That is easy to assert and hard to picture, so having "hello" and "hellp" side by side is a useful teaching and code-review artefact.
• Local by construction: Hashing tokens, licence keys, internal identifiers or customer strings in a web form is a data-handling risk. Here the computation happens in the page, so nothing is logged on a server or held in a request body.

When to use the Hash Generator

Reach for it whenever you need a digest of a short piece of text, or need to work out which digest someone else produced.

• Comparing an expected digest from a vendor, a release note or a Git object against the string you actually hold.
• Building or debugging API request signatures where a body digest feeds into a signature base string, and you need the intermediate value to compare against your code's output.
• Filling in database or ETL fixtures that store a hashed column, so tests use the same digest your application will compute.
• Legacy protocol and firmware work where a CRC-16 (CCITT) field has to be filled in, or a captured frame's checksum has to be reproduced.
• Working out which algorithm an undocumented system uses, by hashing a known sample and comparing widths and values.
• Teaching or reviewing: showing that hashing is one-way, deterministic, and that a one-character edit produces an unrelated output.
• Sanity-checking a migration off MD5 or SHA-1 by computing both the old and new digests for the same records.

How to use the Hash Generator

There is one input and six outputs, and everything recalculates as you type.

1. Paste or type your text: Put the exact string you want to hash in the Input box. Watch for content your editor may have added — a trailing newline or a smart quote changes every digest.
2. Let the digests compute: Results refresh automatically about 150 ms after you stop typing. The status line confirms how many characters were hashed, which is a quick way to catch an invisible trailing space.
3. Read the row you need: MD5, SHA-1, SHA-256, SHA-384, SHA-512 and CRC-16 are listed in that order. Widths are fixed, so a short value means a short input, never a truncated digest.
4. Copy with the row's own button: Each output has a Copy button next to it and the status line confirms which algorithm was copied, so you cannot mix up SHA-384 and SHA-512 when both are on screen.
5. Compare rather than eyeball: To check a digest against an expected value, paste it into the Hash Verification tool instead of reading 128 hex characters by eye — it does a normalised, case-insensitive comparison and tells you match or no match.
6. Clear when you are done: Use the clear control in the input header to wipe the text and reset every row, which is worth doing if the string was sensitive.

Key features

• Six algorithms in parallel: MD5, SHA-1, SHA-256, SHA-384, SHA-512 and CRC-16 (CCITT) all computed from the same input on every keystroke.
• Web Crypto for the SHA family: SHA digests use the browser's native crypto.subtle.digest implementation, so they match what your own JavaScript would produce with the same call.
• MD5 without a server: Web Crypto omits MD5 by design, so a compact bundled implementation fills the gap — useful for legacy systems that still emit MD5 without sending your text anywhere.
• Per-row copy with confirmation: Every digest has its own Copy button, and the status line names the algorithm it copied.
• Input tools built in: The input header carries copy, clear and download controls, so you can save the exact bytes you hashed alongside the digest.
• Fully offline computation: No network request is made at any point; the tool works with DevTools open and the network tab empty.

Common use cases

• API signature debugging: Reproduce the body digest a provider expects (many schemes hash the payload with SHA-256 before signing) and compare it against what your client computed.
• Release and artefact verification: Hash a version string, manifest line or short text artefact and match it against the value published in a changelog or lockfile.
• Legacy system integration: Older SOAP endpoints, licence checks and desktop apps still exchange MD5 digests; compute them here rather than adding a dependency to a modern codebase.
• Embedded and protocol work: Fill in or verify a CRC-16 (CCITT, polynomial 0x1021) field in a serial frame, Modbus-adjacent protocol or firmware header.
• Test fixtures and migrations: Generate the digests your test data expects so unit tests assert real values instead of placeholders, and dual-hash records while migrating from SHA-1 to SHA-256.
• Security review and teaching: Demonstrate avalanche behaviour, digest-length identification, and why MD5 is not acceptable for anything requiring collision resistance.

Examples

Every digest below was computed from the exact bytes shown, with no trailing newline. Widths are fixed, so you can use these as reference vectors.

hello world

MD5: 5eb63bbbe01eeed093cb22bb8f5acdc3
SHA-1: 2aae6c35c94fcfb415dbe95f408b9ce91ee846ed
SHA-256: b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9
SHA-384: fdbd8e75a67f29f701a4e040385e2e23986303ea10239211af907fcbb83578b3e417cb71ce646efd0819dd8c088de1bd
SHA-512: 309ecc489c12d6eb4cc40f50c902f2b4d0ed77ee511a7c7a9bcd3ca86d4cd86f989dd35bc5ff499670da34255b45b0cfd830e81f605dcf7dc5542e93ae9cd76f
CRC-16: efeb

hello
hellp

SHA-256("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
SHA-256("hellp") = fdd7585e08c4e2afd71dcabdb4636c89d557a3f42db9e2040c8bbd1708aa4ce7

abc

SHA-1: a9993e364706816aba3e25717850c26c9cd0d89d
SHA-256: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
SHA-512: ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39a2192992a274fc1a836ba3c23a3feebbd454d4423643ce80e2a9ac94fa54ca49f

MD5: d41d8cd98f00b204e9800998ecf8427e
SHA-1: da39a3ee5e6b4b0d3255bfef95601890afd80709
SHA-256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
CRC-16: ffff

Grüße 世界

MD5: dedb7faef077cde5f8f60a7edd681105
SHA-256: fb2f0df9b28e95c87b4974128fc72253fbc43dc87511568710b9b87c153a951e
CRC-16: c47d

Technical reference

Hard numbers for each algorithm this tool implements:

MD5

128-bit digest, 32 hex characters, 512-bit block, RFC 1321. Collision resistance is broken; RFC 6151 says it must not be used where collisions matter.

SHA-1

160-bit digest, 40 hex characters, 512-bit block, FIPS 180-4. Collisions demonstrated in 2017 (SHAttered) and chosen-prefix collisions in 2020.

SHA-256

256-bit digest, 64 hex characters, 512-bit block, 32-bit words, FIPS 180-4. Current general-purpose default.

SHA-384

384-bit digest, 96 hex characters, 1024-bit block, 64-bit words. A truncated SHA-512 with different initial values, so it resists length-extension.

SHA-512

512-bit digest, 128 hex characters, 1024-bit block, 64-bit words. Often faster than SHA-256 on 64-bit CPUs.

CRC-16 (CCITT)

16-bit checksum, 4 hex characters, polynomial 0x1021, initial value 0xFFFF, no reflection, no final XOR. Check value for "123456789" is 29b1.

Input encoding

UTF-8, via TextEncoder — one byte per ASCII character, two to four bytes for anything above U+007F.

Output format

Lowercase hexadecimal, zero-padded per byte, no separators and no 0x prefix.

Common mistakes to avoid

Using MD5 or SHA-1 where collision resistance is required

Why it happens: Both are comprehensively broken for collisions. MD5 collisions have been produced in seconds on ordinary hardware for well over a decade, and RFC 6151 states plainly that MD5 must not be used where collision resistance is needed. SHA-1 fell in 2017 when the SHAttered team produced two different PDFs with the same digest, and in 2020 Leurent and Peyrin demonstrated a chosen-prefix collision for roughly US$45,000 of rented GPU time — the variant that actually breaks certificates and signatures.

How to avoid it: Use SHA-256 or better for anything where an attacker might supply input: signatures, certificates, content addressing, deduplication of untrusted uploads, or commit identifiers. NIST has said federal agencies must stop using SHA-1 for cryptographic protection by 31 December 2030, which is a good deadline for everyone else too. MD5 and SHA-1 remain acceptable only for non-adversarial uses such as cache keys over trusted data or matching against a legacy system you do not control — and even then, document why.

Treating a hash as a way to store passwords

Why it happens: A raw MD5 or SHA-256 digest is designed to be fast, and speed is exactly what an attacker wants. Commodity GPUs test billions of SHA-256 candidates per second, so a leaked table of unsalted digests is effectively a table of plaintext for any password in a wordlist. Identical passwords also produce identical digests, so one crack reveals every account that reused it, and rainbow tables handle the rest.

How to avoid it: Use a deliberately slow, salted password hash: bcrypt, scrypt or Argon2, with per-user salts and a work factor tuned so verification takes tens of milliseconds on your hardware. The Bcrypt Generator here produces that format. If you have inherited unsalted digests, upgrade opportunistically — rehash each password with a proper KDF the next time the user logs in successfully, and force a reset for accounts that never return.

Confusing CRC-16 with a cryptographic hash

Why it happens: CRC-16 is a linear error-detection code, not a hash function. Its whole purpose is catching accidental bit flips on a wire or in storage, and with 16 bits there are only 65,536 possible values, so unrelated inputs collide constantly. Worse, CRCs are linear over GF(2): given a target checksum, you can compute bytes to append that force any value you like, which makes it useless against deliberate tampering.

How to avoid it: Use CRC-16 only for what it was built for — filling in or checking a protocol or firmware checksum field. For integrity against an attacker, use SHA-256 and, if the data crosses a trust boundary, a keyed construction such as HMAC-SHA-256 so a modified message cannot be re-checksummed. Never accept "the CRC matched" as evidence that a file was not altered.

Comparing digests without normalising the input first

Why it happens: Hashing is byte-exact, so any invisible difference produces a total mismatch. The usual culprits are a trailing newline that a shell or editor appended, CRLF versus LF line endings, a UTF-8 byte-order mark at the start of a file, leading or trailing whitespace from a copy-paste, and typographic quotes substituted by a word processor. SHA-256("hello world") is b94d27b9…, while the same text with one trailing newline is a948904f… — nothing in the output hints at the cause.

How to avoid it: Pin down the exact bytes before you blame the algorithm. The status line here reports the character count, so compare it against what you expect. Use the download control to save the exact input and inspect it with a hex viewer if needed. Where both sides are under your control, agree on a canonical form — trimmed, LF endings, no BOM, UTF-8 — and normalise before hashing on both ends.

Assuming hex case or a 0x prefix does not matter

Why it happens: Digests are bytes; hex is only a rendering, and different tools render differently. Some emit uppercase, some lowercase, some prefix 0x, some group with colons, and some hand you Base64 instead of hex. A string comparison between "B94D27B9…" and "b94d27b9…" fails even though the underlying digests are identical, and Base64 versus hex confuses people further because the same 32 bytes become 44 Base64 characters instead of 64 hex ones.

How to avoid it: Normalise before comparing: lowercase both sides, strip any 0x prefix, remove separators and trim whitespace. The Hash Verification tool does this for you and reports a plain match or no match. When you design a format, state the encoding explicitly, and prefer comparing decoded bytes over comparing text so representation differences cannot cause a false negative.

Frequently asked questions

Which hash algorithm should I use in 2025?

SHA-256 is the sensible default for general-purpose hashing: it is standardised in FIPS 180-4, hardware-accelerated on modern CPUs, and has no practical attacks. Choose SHA-512 or SHA-384 when you want a larger security margin or are on 64-bit hardware where SHA-512 is often faster, and note that SHA-384 also resists length-extension because it is a truncated SHA-512. Avoid MD5 and SHA-1 for anything an attacker can influence. For passwords, do not use a plain hash at all — use bcrypt, scrypt or Argon2. For authenticating a message you also need a key, so use HMAC-SHA-256.

Can a hash be reversed or decrypted?

No. Hashing is not encryption and has no key or inverse: a digest is a fixed 128 to 512 bits regardless of whether the input was one character or a gigabyte, so most of the information is irrecoverably discarded. What "hash cracking" sites actually do is guess — they hash enormous dictionaries and precomputed tables and look for a matching digest. That works well for short, common or low-entropy inputs such as ordinary passwords, which is exactly why salting and slow KDFs exist. For a long random string, no amount of guessing will recover it.

Why does this tool show MD5 if MD5 is broken?

Because plenty of real systems still emit it and you need to interoperate with them. MD5 remains common in legacy APIs, ETag values, package indexes, desktop licence checks and older database columns, and being unable to compute it does not make those systems safer. What is broken specifically is collision resistance — an attacker can build two different inputs with the same digest — so MD5 must not be used for signatures, certificates or content addressing of untrusted data. Using it to match a value a legacy vendor gave you, over data you trust, is a different and much smaller risk.

What is the difference between a hash, a checksum and an HMAC?

They answer different questions. A checksum such as CRC-16 or CRC-32 detects accidental corruption cheaply and can be forged deliberately in moments. A cryptographic hash such as SHA-256 additionally makes it computationally infeasible to find two inputs with the same digest, so it detects tampering as long as the expected digest reached you through a trusted channel. An HMAC adds a secret key, so only someone holding the key can produce a valid tag — that is what proves a message came from the expected sender rather than merely arriving intact. Use the HMAC Generator when authenticity, not just integrity, is the goal.

Why do two hash tools give different results for the same text?

Almost always because the bytes differ, not the algorithm. The most common causes are a trailing newline added by a shell command like echo, CRLF line endings on Windows, a UTF-8 byte-order mark at the start of a file, whitespace picked up in a copy-paste, or non-ASCII text encoded in a different charset. A second, sneakier cause is hashing the text of a value rather than its bytes — for example hashing the Base64 string of a file instead of the file's contents. Compare character counts first, then save both inputs and diff them at the byte level.

Does this tool support SHA-3 or SHA-224?

No. It implements MD5, SHA-1, the three SHA-2 sizes that browsers expose natively — SHA-256, SHA-384 and SHA-512 — plus CRC-16. Web Crypto's digest method does not offer SHA-224, SHA-512/256, or the SHA-3 family from FIPS 202, so those would require shipping a large extra implementation for algorithms that very few integrations ask for. In practice SHA-256 covers almost every case where you might reach for SHA3-256, and NIST treats both SHA-2 and SHA-3 as approved. If you specifically need Keccak or SHA-3 output, use a language runtime that provides it.

How long does it take to compute a SHA-256 hash?

Microseconds for the kind of text you paste into a box. Modern CPUs process hundreds of megabytes to several gigabytes per second, and many have dedicated SHA instructions, so the 150 ms delay you see here is a deliberate debounce that waits for you to stop typing, not computation time. That speed is a feature for integrity checking and a liability for password storage, which is the entire reason purpose-built password hashes are designed to be slow and memory-hungry instead.

References

• FIPS 180-4 — Secure Hash Standard (SHS)
• RFC 1321 — The MD5 Message-Digest Algorithm
• RFC 6151 — Updated Security Considerations for MD5 and HMAC-MD5
• SHAttered — the first collision for full SHA-1
• NIST — Transitioning away from SHA-1 for all applications