Where is the MD5 option?

On its own page, the MD5 generator. Web Crypto, the browser API this page uses, deliberately omits MD5, so it needs a separate implementation, and keeping it apart means this page never loads code for a digest that is broken for security. Use MD5 only to check an old download that publishes nothing else; for anything new, use SHA-256 here.

Can I hash a password here?

You can, but the result is worthless as a stored credential. SHA-256 is designed to be fast, and fast is exactly wrong for passwords, because a consumer GPU tries billions of guesses a second against it. Password storage needs a slow, salted function such as bcrypt, scrypt or Argon2, running on your server, where the work factor and the salt live.

Is SHA-1 still safe to use?

Not for signatures or for anything an attacker benefits from forging. A practical collision was demonstrated in 2017 and the cost has only fallen since. It is still fine for spotting accidental corruption, and it stays on the page because Git object IDs, older webhook signatures and legacy checksum files use it, and you occasionally need to reproduce one.

Does the text I type get uploaded anywhere?

No. The digest is computed by your browser's own crypto.subtle implementation, the same code path a Node or Python library calls into. No request is made to hash anything, so a key fingerprint or an unreleased document is as safe here as in a local terminal.

Why does my terminal produce a different digest for the same text?

Almost always a trailing newline. Piping echo hello into sha256sum hashes six bytes rather than five, because echo appends a line break; printf without a newline hashes five. Check the file encoding too, since this page hashes UTF-8 and a file saved as latin-1 or UTF-16 holds different bytes for the same visible characters.

Hash text without uploading it

What this tool does

This hash generator computes the SHA-1, SHA-256, SHA-384 and SHA-512 digest of whatever you type, all four at once, and shows each as lowercase hex, uppercase hex or Base64. It calls your browser's own crypto.subtle implementation, so the text never leaves the tab — which is why you can paste a certificate fingerprint or an unpublished draft into it without thinking twice.

There is also a comparison field. Paste the checksum a project published next to its download and the tool tells you which algorithm it matches, if any. It accepts the whole sha256sum line, file name included, so you can copy straight from a release page.

How to use it

Type or paste your text. The four digests update as you type; an empty box still has a digest, because the empty string does.
Pick hex or Base64. Hex is what checksum files use; Base64 is what turns up in subresource integrity attributes and in a lot of JSON APIs.
Copy one digest with the button beside it, or copy the whole block for a ticket.

Why MD5 lives elsewhere and bcrypt nowhere

Both omissions are deliberate, and for opposite reasons.

MD5 is broken, and Web Crypto refuses to implement it. Collisions have been cheap since 2004 — two different files with the same MD5 can be produced on a laptop. Every browser vendor left it out of crypto.subtle on purpose. For the old download that only publishes an MD5, there is a separate MD5 generator with its own implementation, so this page never loads it. Anything new should publish SHA-256.

bcrypt is the opposite problem: too slow, on purpose, and in the wrong place. A password hash is supposed to be expensive, with a cost factor tuned so each verification takes tens of milliseconds. That cost is the entire defence, and it belongs on a server where you control the work factor and the salt and where the result is stored. A password hashed in a browser tab and then sent onward is just a longer password, travelling through a page you did not write. Hash passwords on the server, with bcrypt, scrypt or Argon2. Nothing here is a substitute for that.

MD5 vs SHA-256

The question usually typed as md5 vs sha256 has a short answer and one reason behind it. MD5 gives 128 bits, written as 32 hex characters; SHA-256 gives 256 bits, written as 64. Against accidents — a truncated download, a bit flipped on a failing disk — the two are equally good, and the shorter digest is no weakness. The difference is an adversary. Two different inputs with the same MD5 can be produced in seconds, so an MD5 match cannot prove that nobody replaced the file. No practical collision is known for SHA-256, which is why package managers, certificate authorities and Git's newer object format settled on it.

Speed is not an argument for MD5 either. On processors with SHA extensions SHA-256 runs close to MD5, and for text hashed in a browser tab the difference is invisible. So the rule is simple: check an MD5 only when it is the only checksum a project offers, and publish SHA-256 for anything of your own.

Which SHA to pick

For anything new, SHA-256 is the default, and the reasoning is boring: fast on modern processors, hardware-accelerated on most of them, supported everywhere.

SHA-512 is not merely a longer SHA-256 — it works on 64-bit words, so on a 64-bit CPU it is often faster than SHA-256 despite producing twice the output. If you are hashing large volumes on server hardware, measure rather than assume.

SHA-384 is SHA-512 truncated to 384 bits, with different initial values. It exists mostly because TLS cipher suites and some certificate profiles ask for it by name.

SHA-1 is here for compatibility, not for security. Git object IDs, older signature headers and long-lived checksum files still use it, and reproducing one is a legitimate need. Never choose it for something new.

The trailing newline that wastes an afternoon

When the digest here disagrees with the one from your terminal, the input almost certainly differs by a single byte. Piping echo hello into sha256sum hashes six bytes because echo adds the line break; printf 'hello' hashes five. The same trap hides at the end of files: an editor set to "ensure a final newline" changes a file's digest, silently, on save.

Encoding is the second suspect. This page encodes your text as UTF-8 before hashing, which is what the web and every modern toolchain do. A file saved as UTF-16 or latin-1 holds different bytes for the same visible characters, and different bytes mean a different digest — correctly so.

What a hash proves, and what it does not

A matching digest proves the bytes are identical to the bytes the publisher hashed. It proves nothing about whether the publisher is honest, and nothing at all when the checksum and the download come from the same compromised page. That is what signatures are for: a checksum tells you the file arrived intact, a signature tells you who put it there.

Need identifiers rather than fingerprints? The UUID generator produces unique values without hashing anything. Working out permissions on the server you are deploying to? The chmod calculator turns the octal into plain English.

Hash Generator