Hashes, computed
in your browser

Type or paste text to get its SHA-1, SHA-256, SHA-384, and SHA-512 digests at once, in hex or Base64. Free, no sign-up required.

Input

0characters · hashing an empty input is valid and gives each algorithm's well-known empty digest

SHA-1

SHA-256

SHA-384

SHA-512

Features

Everything you need to compute and check a digest.

Four algorithms at once

SHA-1, SHA-256, SHA-384, and SHA-512 are all computed from the same input, so you do not need to know which one you want first.

Hex or Base64

Switch the output encoding to match whatever you are comparing against, since the same digest is written both ways in the wild.

Checksum comparison

Paste a published checksum and the matching algorithm is identified and highlighted, rather than leaving you to compare 64 characters by eye.

Web Crypto, in your browser

Digests are computed by the browser’s own cryptographic implementation. Nothing you type is transmitted.

How to generate a hash

Three steps, and every digest updates as you type.

Enter the text

Type or paste anything. All four digests recompute as you go, including for an empty input.

Pick an encoding

Hex is the usual form for checksums. Base64 is common in signatures, subresource integrity, and HTTP headers.

Compare or copy

Paste a checksum into the compare box to find which algorithm it matches, or copy any digest with one click.

When you need this

Where a digest is the right tool for the job.

Verifying a download

Projects publish a SHA-256 of each release. Comparing it confirms the file arrived intact and unmodified.

Building a cache key

Hashing a request body or a set of parameters gives a fixed-length key that changes whenever the input does.

Checking for duplicate content

Two pieces of text with the same digest are byte-identical, which is a cheaper comparison than the text itself.

Generating an integrity attribute

Subresource integrity uses a Base64 SHA digest so a browser can refuse a script that has been tampered with.

Understanding cryptographic hashes

What separates a cryptographic hash from an ordinary one, why MD5 and SHA-1 were retired, how to verify a download in a way that actually proves something, and why passwords need a different kind of function entirely.

What makes a hash function cryptographic

Any function that maps arbitrary input to fixed-size output is a hash. A cryptographic hash adds three properties that non-cryptographic ones do not guarantee.

Preimage resistance — Given a digest, it is infeasible to find any input that produces it. This is what makes a digest safe to publish.
Second preimage resistance — Given one input, it is infeasible to find a different input with the same digest. This is what makes a checksum meaningful.
Collision resistance — It is infeasible to find any two inputs that share a digest. This is the strongest requirement, and the first one to fall when an algorithm ages.

Non-cryptographic hashes such as CRC32 or MurmurHash are excellent for hash tables and error detection, and offer none of these guarantees. Using one where an adversary is involved is a security bug.

Why MD5 and SHA-1 are retired

Both fell to collision attacks rather than preimage attacks. Nobody can take a SHA-1 digest and recover the input, but producing two different documents with the same SHA-1 digest is now practical, which was demonstrated publicly in 2017 with two PDFs.

That is enough to break anything relying on a digest to identify content uniquely: certificate signing, code signing, and tamper detection all depend on collision resistance rather than preimage resistance.

MD5 is far worse. Collisions can be generated in seconds on a laptop, and have been used to forge certificates in the wild.

Both remain fine for non-adversarial uses such as detecting accidental corruption or deduplicating your own files. The distinction is whether anyone has an incentive to construct a collision.

Verifying a download properly

Comparing a published checksum against one you compute detects corruption in transit and, sometimes, tampering. Whether it detects tampering depends entirely on where the checksum came from.

If the checksum sits on the same page as the download link, an attacker who can alter one can alter the other, and the check proves only that the file transferred cleanly. The check becomes meaningful when the checksum arrives by a different route: a signed release file, a separate domain, or a repository you already trust.

This is why serious projects sign their checksum files with a key rather than simply publishing them. The signature is what ties the digest to an identity.

Salting, and why it is not optional

Hashing the same input always gives the same digest, which means identical passwords produce identical hashes. An attacker who steals a password database can spot every account using the same password, and can precompute digests of common passwords once and look them all up at speed.

A salt is a unique random value stored alongside each hash and mixed into it before hashing. Identical passwords then produce different digests, and precomputed tables become useless because they would have to be built per salt.

Salts are not secret and do not need to be. Their entire job is to be different for every record.

Modern password hashing functions generate and store the salt for you as part of their output format, which is one more reason to use one rather than assembling the pieces yourself.

Hex, Base64, and the same digest

A digest is a sequence of bytes: 32 for SHA-256, 64 for SHA-512. How it is written down is a separate choice, and the same digest looks completely different in the two common forms.

Hexadecimal uses two characters per byte, giving 64 characters for SHA-256. It is the convention for checksums because it is easy to compare visually and safe everywhere.

Base64 is more compact at about 44 characters for the same digest, and is used where length matters: subresource integrity attributes, HTTP header values, and signatures.

SHA-256 of "abc"

hex:    ba7816bf8f01cfea414140de5dae2223
        b00361a396177a9cb410ff61f20015ad
base64: ungWv48Bz+pBQUDeXa4iI7ADYaOWF3qc
        tBD/YfIAFa0=

If a digest does not match what you expected, check the encoding before assuming the content differs. A hex digest compared against a Base64 one will never match.

Common questions

What is a hash function?

A hash function maps input of any size to a fixed-size output, deterministically. The same input always gives the same digest, a different input almost certainly gives a different one, and the digest reveals nothing practical about the input. Changing a single character changes roughly half the output bits.

Can a hash be reversed?

Not by computation. A digest discards information, so there is no inverse function. The realistic attack is guessing: hashing likely inputs until one matches. That is why hashing a short, predictable value such as a password with a fast algorithm offers very little protection.

Why is MD5 not offered?

MD5 is cryptographically broken, with collisions producible in seconds on ordinary hardware. The Web Crypto API deliberately does not implement it, and adding a library to provide a hash nobody should use for anything new is not a worthwhile trade. Use SHA-256 unless you are verifying an old checksum that was published as MD5.

Should I use this to hash passwords?

No. SHA-family functions are designed to be fast, which is exactly wrong for passwords: it lets an attacker with a stolen database try billions of guesses per second. Passwords need a deliberately slow, salted algorithm such as bcrypt, scrypt, or Argon2, run on your server.

Which SHA should I choose?

SHA-256 for almost everything. It is widely supported, fast, and has no known practical weakness. SHA-512 is often faster on 64-bit hardware and gives a larger margin. SHA-1 should only be used to check against an existing legacy digest, since collisions against it have been demonstrated in practice.