Compute the four most common digests of any text or file at once. SHA-1, SHA-256 and SHA-512 are produced by the browser’s native Web Crypto API — the same hardware-accelerated implementation used for TLS — while MD5 is included for legacy checksum comparison. Type into the box or pick a file and every hash appears immediately, ready to copy with one click in lowercase or uppercase hexadecimal. The file is read locally with the File API and never uploaded.
How to generate a hash
- 1 Type or paste your text — or choose a file to hash instead.
- 2 All four digests are calculated instantly as you type.
- 3 Toggle uppercase if the system you are comparing against expects it.
- 4 Click Copy next to the digest you need.
Which algorithms run where
SHA-1, SHA-256 and SHA-512 come from the Web Crypto API through crypto.subtle.digest. That is the browser’s own cryptographic implementation — hardware-accelerated on most processors, audited as part of the browser, and adding nothing to the page weight. MD5 is not part of Web Crypto, because browsers deliberately excluded it as a broken algorithm, so it ships here as a small self-contained implementation for the one thing it is still legitimately used for: comparing a checksum published by someone who has not moved on.
There is a subtle detail in how file bytes are handled. Some file readers hand back a view over a larger shared buffer rather than an exactly-sized one, and hashing that view directly would digest the surrounding bytes as well, producing a wrong result that looks perfectly plausible. The bytes are therefore copied into a fresh, exactly-sized buffer before hashing. Digests are returned as lowercase hexadecimal, which is what checksum files and verification pages almost always publish.
Text is encoded as UTF-8 before hashing, so accented characters and emoji produce the same digest here as they would in any correctly-implemented tool. A hash is not reversible: it is a one-way function producing a fixed-length fingerprint, and the only way to find the input for a given digest is to guess inputs until one matches.
What hashes are actually for
Verifying a download
A project publishes the SHA-256 of its installer. Hash the file you downloaded and compare: if the digests match, the file is byte-for-byte what was published and was not corrupted or tampered with in transit.
Checking two files are identical
Comparing digests is far faster than comparing multi-gigabyte files, and works when the two copies are on different machines. Identical digests mean identical content.
Detecting silent corruption
Hashing an archive when you store it and again years later reveals bit rot on failing drives — the kind of damage that produces no error message until you try to open the file.
Cache keys and deduplication
A content hash makes a stable identifier for a file, which is how build tools name assets and how backup systems avoid storing the same file twice.
What hashes are for
A hash is a fixed-length fingerprint of some data: the same input always produces the same digest, and any change — a single byte — produces a completely different one. That makes hashes the standard way to verify a download, compare two files without opening them, deduplicate content, or check that a transfer arrived intact. For integrity or security work choose SHA-256 or SHA-512; MD5 and SHA-1 are cryptographically broken and should be used only to match a checksum published by a legacy system, never to protect passwords or sign data.
Serious warnings about the weak algorithms
Two of the four algorithms offered here are broken for security purposes. They are included for compatibility, not endorsement:
- MD5 is comprehensively broken. Collisions — two different inputs with the same digest — can be produced in seconds on a laptop. Use it only to compare against a legacy checksum, never to verify that a file has not been tampered with by someone who wanted to tamper with it.
- SHA-1 is also broken. A practical collision was demonstrated in 2017, and every major browser and certificate authority abandoned it. Treat it exactly like MD5: for legacy comparison only.
- No hash on this page is suitable for storing passwords. Password storage needs a deliberately slow algorithm designed for the job — bcrypt, scrypt or Argon2 — because fast hashes make brute-force attacks fast too. SHA-256 is fast by design, which is precisely the wrong property.
- A matching hash proves the bytes match, not that the source is trustworthy. If an attacker controls the page publishing the checksum as well as the file, both will agree.
- Very large files are limited by memory, since the file must be read into the tab before it can be hashed.
Troubleshooting
- My hash does not match the published one
- Check the algorithm first — a SHA-256 digest will never match a published SHA-512. Then check for a truncated or incomplete download by comparing file sizes. If both are right, the file genuinely differs from the published one, and you should not run it.
- The same text gives a different hash elsewhere
- Almost always a trailing newline or different line endings. Many tools hash a file that ends with a newline character, while pasted text does not, and a Windows CRLF differs from a Unix LF. A single invisible byte changes the entire digest.
- Hashing a large file is slow or fails
- The file has to be read into the browser tab in full. Multi-gigabyte files can exhaust available memory. For those, a command-line tool — sha256sum on Linux, shasum on macOS, certutil -hashfile on Windows — streams the file instead.
Frequently asked questions
Is my file uploaded to compute the hash?
No. The file is read locally with the browser File API and hashed on your device. Nothing is transmitted, which also means large files are limited only by your own memory.
Why is MD5 marked as legacy?
MD5 and SHA-1 are vulnerable to collision attacks and browsers no longer expose MD5 through Web Crypto. They remain useful for verifying checksums published by older systems, but never for passwords, signatures or security decisions.
Can I hash a password with this?
You can, but you should not store it that way. Passwords need a slow, salted algorithm such as bcrypt, scrypt or Argon2 — a raw SHA digest is far too fast to be safe.
Can a hash be reversed to recover the original?
No. Hashing is one-way and discards information — a digest is a fixed 256 bits no matter whether the input was one character or one gigabyte. What "hash cracking" services actually do is look the digest up in a precomputed table of common inputs, which works for "password123" and not for anything unpredictable.
Which algorithm should I use?
SHA-256 for essentially everything. It is the current standard, universally supported, and no practical attack exists against it. SHA-512 is a reasonable choice for long-term archival and is sometimes faster on 64-bit processors. Use MD5 or SHA-1 only when you have to match a checksum somebody else already published.
Is my file uploaded to be hashed?
No. The file is read into your browser’s memory and hashed there with the Web Crypto API. Nothing is transmitted — which is what makes it reasonable to hash a confidential document, something you should never do on a server-side hashing service.
Why do MD5 and SHA-1 carry a warning here?
Because presenting all four algorithms as equivalent would be misleading. Both are trivially collidable, meaning an attacker can construct a malicious file with the same digest as a legitimate one. They remain useful for spotting accidental corruption and for matching old published checksums, and nothing else.