QuickUse Generator

Hash Generator

MD5, SHA-1, SHA-256, SHA-384 and SHA-512 digests in hex, Base64 or Base64URL. 100% client-side — your input never leaves the browser.

Mode
0 / 10000 chars
Output
The hash appears here as you type.

Editorial guide

About this generator

An honest technical read on what is happening behind the Generate button.

Hash functions are the cryptographic plumbing of the modern web. Every Git commit you push, every ETag your CDN returns, every IPFS link, every password manager, every TLS handshake depends on them. Generating one in your browser should be boring and instantaneous — and that is exactly what this tool does.

What a hash function actually does

A cryptographic hash takes an input of any length and produces a fixed-length digest — 128, 160, 256, 384, or 512 bits, depending on the algorithm. The mapping is deterministic (the same input always yields the same output), one-way (you can't run it backwards), and collision-resistant (it is computationally infeasible to find two inputs with the same digest, at least for the modern algorithms). That single primitive underpins content addressing in Git, file integrity verification in package managers, deduplication in object storage, and rate-limiting tokens in web APIs.

Three properties matter when you pick one: collision resistance (how hard is it to forge a second input?), output length (longer is better for unique identifiers at scale), and speed (every byte you hash is CPU you can't spend elsewhere).

Five algorithms, three eras

MD5 (Rivest, RFC 1321, April 1992) is the oldest of the five. It produces a 128-bit digest in roughly 6 cycles per byte on modern CPUs and remains the fastest option for non-security checksums. Don't use it where collision resistance matters — see the next section.

SHA-1 (NIST, 1995) produces a 160-bit digest. For a long time it was the industry default for digital signatures and Git's content-addressing key. It is now deprecated for security uses; Git is actively migrating to SHA-256.

The SHA-2 family — SHA-256, SHA-384, and SHA-512 — was specified by NIST in FIPS 180-4 and represents the modern baseline. SHA-256 is what TLS certificates, Bitcoin, modern Git, and almost every new system reach for by default. SHA-384 shows up in TLS 1.3 cipher suites. SHA-512 is faster than SHA-256 on 64-bit CPUs (it operates on 64-bit words natively) but produces a longer digest — useful when you want a wide collision margin or are deriving multiple sub-keys from one hash.

Why MD5 and SHA-1 should never sign anything

In August 2004 Xiaoyun Wang and her team at Shandong University announced practical collisions against MD5 at the CRYPTO 2004 rump session; the full attack appeared the following year in Advances in Cryptology — EUROCRYPT 2005 (LNCS 3494, pp. 19–35). Within months, researchers were generating colliding PostScript and PDF files. By 2008, a chosen-prefix attack let researchers forge a rogue Certificate Authority. MD5 has been off the table for digital signatures and certificate authorities ever since.

SHA-1 followed a slower decline. Theoretical attacks began appearing in 2005. On 23 February 2017 CWI Amsterdam and Google jointly announced SHAttered — the first practical SHA-1 collision, in the form of two PDF files with the same digest. The attack cost roughly US$110,000 of AWS compute. Browsers and certificate authorities deprecated SHA-1 certificates over the following year; Microsoft and Mozilla dropped support for new SHA-1 certificates entirely.

What does a collision actually let an attacker do? It enables signature forgery: if you sign hash(X) and the attacker can find Y with hash(Y) = hash(X), your signature retroactively covers Y. That's why deprecated algorithms are dangerous for digital signatures, TLS certificates, password reset tokens, and code-signing — anywhere a hash is committing you to a payload you can't see all the bytes of.

When MD5 and SHA-1 are still fine

Collision resistance is the property that fails. The other properties — determinism, one-wayness for unknown inputs, and uniform output distribution — still hold. So MD5 and SHA-1 remain perfectly serviceable for non-adversarial uses: file checksums against accidental corruption, dedup keys for content-addressed caches, ETag-style cache invalidation, partitioning inputs across shards. The rule of thumb is if an attacker who controls the input gains nothing by colliding it, you can use the cheap hash. If anything in your threat model relies on "two different inputs can't produce the same digest", switch to SHA-256.

Where these algorithms actually sit in production

The five algorithms are not interchangeable trivia — each one has a specific installed base you might be talking to. SHA-256 is what Bitcoin's proof-of-work hashes, what every modern TLS certificate is signed with, and the target of Git's ongoing object-format migration (the "transition to SHA-256" plan has been in the official roadmap since 2018, and Git 2.42 made SHA-256 repositories interoperable with traditional SHA-1 ones). IPFS content addressing wraps SHA-256 in a Multihash prefix so future algorithms can coexist without a flag day.

SHA-512 is the workhorse inside HMAC-SHA-512, which AWS Signature Version 4 uses to sign every API request you make against S3, DynamoDB, or Lambda. It is also the inner hash of Linux's /etc/shadow when you see a $6$ prefix. SHA-384 shows up in TLS 1.3 cipher suite identifiers (TLS_AES_256_GCM_SHA384) and as the digest paired with ECDSA-P384 in interoperability profiles published by NIST and CNSA. Knowing the downstream consumer is usually how you decide which one to feed: pick the algorithm that survives a copy-paste into the system on the other end.

Hex, Base64, Base64URL — three views of the same bytes

The digest is a sequence of bytes. How you render them is a separate question. Hex is the universal representation: every byte becomes exactly two characters from [0-9a-f], so length is predictable and the rendering is locale-safe. The output is roughly twice as long as the raw bytes; for SHA-256 you get 64 characters.

Base64 packs three bytes into four printable characters, so the rendered string is about 33% longer than the raw bytes (rather than 100% longer for hex). It is the default representation in HTTP basic auth, S/MIME, and many storage APIs. It uses + and / in the alphabet plus = as padding, which makes it unsafe to drop directly into URLs.

Base64URL (RFC 4648 §5) fixes that: it substitutes - for + and _ for /, and the padding is usually stripped. The result is URL-safe and filename-safe. JSON Web Tokens, OAuth 2.0 PKCE, and the modern web platform all speak Base64URL natively. If you are integrating with anything in the JWT or OAuth ecosystem, this is the format you want.

Verify mode: when a hash already exists

The Verify tab takes an input and an expected digest, and tells you whether they match. Three real-world workflows lean on this:

  • Download integrity. A vendor publishes a SHA-256 alongside an installer or container image. You paste both into Verify mode and confirm the bytes you have are the bytes the vendor intended.
  • Content addressing. Git and IPFS identify objects by their hash. Verify mode lets you confirm a payload still corresponds to a known identifier without writing a script.
  • Token comparison. A reset link contains token_hash=... and your backend stores the same value. You paste both and confirm the round-trip without running anything server-side.

The comparison is tolerant: hex matches regardless of case, padded Base64 matches unpadded Base64URL when the underlying bytes are the same, and trailing whitespace is ignored. Internally we compare the decoded bytes in constant time — it doesn't matter for a user-typed expected hash, but it's the right habit when the same primitive will later be reused for HMAC verification.

Privacy: nothing leaves your browser

Server-side hash generators leak the input you typed via load balancer logs, proxy intermediaries, application logs, and any analytics middleware that captures POST bodies. That matters when the input is a password, a recovery phrase, a personal identifier, or a draft document. This tool hashes locally — the W3C Web Cryptography API's SubtleCrypto.digest() reached Recommendation status in January 2017 and is shipped in every evergreen browser. The MD5 implementation is plain JavaScript (Web Crypto deliberately excludes MD5), bundled with the page. No network requests.

The "Recent inputs" sidebar is a privacy-preserving convenience: it remembers your recent inputs and which algorithm you selected, so you can iterate on the same payload without re-pasting it. It deliberately does not remember the resulting hash — when you click a recall entry, the hash is recomputed in milliseconds. A regulator-style inspection of the stored payload (or just localStorage.getItem('recent-inputs:hash-generator:v1') in your devtools) will show you only the input, the algorithm tag, and the timestamp. This matters in jurisdictions like Brazil, where the LGPD's pseudonimização guidance under Article 12 treats reversible mappings as still-personal-data and ANPD's 2024 draft anonymization guide encourages designs where the sensitive output never lands on disk.

Frequently asked questions

Is it safe to type a password into a hash generator?

Into this one, yes — everything runs in your browser, nothing is sent to a server, and the recent-inputs sidebar deliberately does not persist the hash. That said, "hash this password and store it" is rarely the right pattern. Real password storage uses a slow KDF like Argon2 or bcrypt with a per-user salt; a single SHA-256 of a password is brute-forceable in minutes on commodity GPUs.

Which algorithm should I pick by default?

SHA-256. It is the modern baseline, what TLS certificates use, what Bitcoin uses, what Git is migrating to. Pick SHA-512 when you specifically benefit from longer output or 64-bit word performance. Pick MD5 or SHA-1 only when you need cross-compatibility with an existing system and collision resistance is not in your threat model.

Can MD5 or SHA-1 be reversed?

No — hash functions are one-way. What attackers do is build huge tables of (input → digest) pairs for common inputs (rainbow tables) or run massive offline guessing. For uncommon inputs the digest leaks almost nothing on its own. The reason MD5 and SHA-1 are deprecated is not reversibility, it is the ability to find two different inputs that produce the same digest.

Why is my Base64URL output shorter than the standard Base64?

Base64URL (RFC 4648 §5) strips the trailing "=" padding by default — there is no information loss because the unpadded length tells you how many bytes are encoded. Many libraries accept padded input on decode, which is why this tool tolerates both shapes in Verify mode.

Does the Verify mode tolerate uppercase vs lowercase hex?

Yes. Internally we decode the expected hash to bytes and compare bytes — casing in the hex representation has no effect. Padded Base64 will also match unpadded Base64URL when the underlying bytes are identical.

What happens to my input if I close the browser tab?

The current input field is cleared. The "Recent inputs" sidebar is the only thing that survives a reload, and it stores only the input string, the algorithm name, and a timestamp — never the hash output. You can clear it any time with the Clear button.

How do I verify a downloaded file against a SHA-256 checksum?

In this UI you would paste the file contents into the input (works for small text files). For binary files use your OS tool: macOS shasum -a 256, Linux sha256sum, Windows certutil -hashfile <file> SHA256. Take the resulting digest and paste it into Verify mode along with the file content (or compare digests visually if both sides produced hex).

Why is SHA-3 not in the dropdown?

Web Crypto’s SubtleCrypto.digest() does not implement SHA-3 (Keccak) — adding it would require a ~10KB polyfill. Specs are tracking it; we will add SHA-3 if browser support lands or if the audience asks for it.