Free

Hash Generator

Six algorithms, computed locally, with the broken ones clearly labelled as broken - and a straight answer about which of them belongs near a password.

  • Free forever
  • No signup
  • Runs in your browser

At a glance

Takes
Any text, in the encoding you choose
Returns
MD5, SHA-1, SHA-256 and SHA-512, computed at once
Handles
Says plainly which of these is safe for what - and none of them is for passwords
Privacy
Hashed in your browser using the platform's own WebCrypto

Nothing you type leaves this page

This tool runs entirely in your browser. Nothing you type or paste is sent to Revquix or to anyone else, no account is needed, and the page keeps working with your network disconnected.

Full detail in our privacy policy and AI policy.

How this works

About Hash Generator

What it checks, what it deliberately does not, and how to read the output.

Where each digest comes from

The SHA family is computed by your browser's own Web Crypto implementation, which is typically native code and is the same implementation everything else in your browser uses, so a mismatch is impossible by construction. MD5 and CRC32 are computed here in JavaScript, because neither is in the Web Crypto specification - MD5 was excluded deliberately, since the working group did not want a broken hash to be a one-liner in every browser, and CRC32 is not a hash at all.

One consequence worth knowing: Web Crypto is only available in a secure context, so on a plain HTTP page the SHA algorithms genuinely cannot run. This tool says so explicitly rather than producing nothing, because an empty result looks like a problem with your input.

MD5 and SHA-1 are here, and they are labelled

Both are broken against an adversary. MD5 collisions can be produced in seconds, and SHA-1's first practical collision was demonstrated in 2017. Neither proves that a file came from where it claims to.

They are still computed here because they are still genuinely needed: MD5 is the ETag and Content-MD5 of a decade of APIs and the published checksum of thousands of artefacts, and SHA-1 is what git uses for object ids. Withholding them would push you to a tool that says nothing at all about their weakness, which is worse. So they compute, with the caveat next to the value.

  • SHA-1, SHA-256, SHA-384, SHA-512 via Web Crypto
  • MD5 to RFC 1321, verified against the specification's own test vectors
  • CRC32 with the IEEE polynomial that ZIP, PNG and gzip use
  • Hex and Base64 output - the latter is what Content-MD5 and Subresource Integrity carry

No hash here belongs near a password

This is the single most consequential misuse of the thing this page computes, so it is worth being blunt: SHA-512 is not a safe password hash, and neither is SHA-256 with a salt. Speed is the entire purpose of a general-purpose hash and the entire problem for a password, because it is exactly what makes brute-forcing cheap - a commodity GPU tries billions of SHA-256 guesses per second. Passwords need bcrypt, scrypt or Argon2, which are deliberately slow and deliberately memory-hard.

What it will not do

It hashes text, not files. A file hash is a genuinely useful thing to want, and it is also a one-line shell command - shasum -a 256 yourfile - that does not require trusting a web page with the file.

It also will not reverse a hash. Nothing can: a hash is one-way by design, and the services that claim otherwise are looking your value up in a table of precomputed common inputs, which works only for short or unsalted ones. And it does not compute HMACs, which need a key and are a different operation.

FAQ

Questions people actually ask

The ones that come up before somebody uploads anything.

Can I use SHA-256 to hash passwords?

No. A general-purpose hash is designed to be fast, which is precisely what makes password brute-forcing cheap - a commodity GPU manages billions of SHA-256 attempts per second. Adding a salt helps against precomputed tables but does not fix the speed. Use bcrypt, scrypt or Argon2, which are deliberately slow and memory-hard.

Is MD5 safe to use for anything?

For non-adversarial purposes, yes: a cache key, a change-detection checksum, an ETag, verifying a download against a checksum published by someone you already trust. It is not safe wherever someone might deliberately construct a collision, which rules out signatures, integrity against tampering and any security decision.

Why do I get a different hash than another tool?

Almost always a difference in the input bytes rather than in the algorithm. A trailing newline is the usual culprit, followed by line endings - CRLF against LF - and text encoding. Hashing is byte-exact, so a single invisible character changes every digit of the output.

Can a hash be reversed?

No. Hashing is one-way by construction. Sites that appear to reverse one are looking the value up in a table of previously computed common inputs, which is why unsalted hashes of short passwords are effectively public and why salting exists.

Is my input sent to a server to be hashed?

No. The SHA algorithms run in your browser's Web Crypto implementation and MD5 and CRC32 run in JavaScript on the same page. Nothing is transmitted, which is what makes it reasonable to hash something sensitive here - although a shell command remains the better habit for a real secret.

Next, try one of these

More from Developer, or browse the full catalogue.

This is an interview question

“Why can you not hash passwords with SHA-256?”

Fast hashes, salts, work factors and why bcrypt or Argon2 exists is asked in almost every backend security round, and a one-line answer is not what gets you through the follow-ups. A mock interview with a verified engineer tells you how far your version actually goes.

Mock Interview from ₹599