Security & devFree
Free hash generator for SHA-256, SHA-512, SHA-384, and SHA-1. Hash text locally with Web Crypto. No upload.
Last updated 4 October 2026
Uses Web Crypto in your browser. MD5 is not available in Web Crypto and is omitted on purpose (legacy).
The menu above offers four hash functions. All four are specified in FIPS 180-4, Secure Hash Standard, and the standard’s own properties table is the fastest way to know what you are choosing between:
| Algorithm | Digest (bits) | Hex characters | Block (bits) | Word (bits) | Max message (bits) |
|---|---|---|---|---|---|
| SHA-1 | 160 | 40 | 512 | 32 | < 264 |
| SHA-256 | 256 | 64 | 512 | 32 | < 264 |
| SHA-384 | 384 | 96 | 1024 | 64 | < 2128 |
| SHA-512 | 512 | 128 | 1024 | 64 | < 2128 |
The hex-character column is the one people actually use, because it is how you recognise a digest in the wild: 40 characters means SHA-1, 64 means SHA-256, 128 means SHA-512. The counter beside the Hash button prints that length back to you for exactly this reason.
FIPS 180-4 describes what these are for in one sentence, and it is narrower than most people assume: the algorithms “enable the determination of a message’s integrity: any change to the message will, with a very high probability, result in a different message digest.” Not encryption, not storage, not identity. Change detection.
FIPS 180-4 specifies seven functions: “SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256”. A separate standard, FIPS 202, specifies the SHA-3 family and the two extendable-output functions. A browser gives you four of the eleven. The W3C Web Cryptography API is explicit about which: “The recognized algorithm names are ‘SHA-1’, ‘SHA-256’, ‘SHA-384’, and ‘SHA-512’ for the respective SHA algorithms.”
| Specified in a FIPS standard | Available in a browser |
|---|---|
| SHA-1, SHA-256, SHA-384, SHA-512 | Yes, all four, and they are the four in the menu above |
| SHA-224, SHA-512/224, SHA-512/256 | No |
| SHA3-224, SHA3-256, SHA3-384, SHA3-512 | No |
| SHAKE128, SHAKE256 | No |
| MD5 | No, and it is not a FIPS standard either |
So if you came here for SHA3-256 or SHA-224, no browser-based tool can give it to you without shipping its own implementation, and you should be suspicious of one that claims to without saying so. FIPS 202 positions SHA-3 as an alternative rather than a replacement: its functions “supplement the SHA-1 hash function and the SHA-2 family of hash functions that are specified in FIPS 180-4”. SHA-256 is not deprecated and there is no migration you are behind on.
MD5 is absent for two independent reasons, and it is worth separating them. The first is mechanical: the string “MD5” does not occur anywhere in the Web Cryptography API specification, so the browser simply has no entry point for it. The second is that it should not be used for this job anyway. RFC 6151, March 2011: “MD5 is no longer acceptable where collision resistance is required such as digital signatures.” Note what that sentence does not say. The same RFC treats HMAC-MD5 separately, observing that attacks on it “do not seem to indicate a practical vulnerability when used as a message authentication code”, while still advising that “new protocol designs should not employ HMAC-MD5”. “MD5 is broken” is true in the way that matters and false as a blanket statement, and the distinction is the same one that governs SHA-1 below.
A hash function is asked to be hard in three distinct ways, and NIST SP 800-107 Rev. 1 defines each with its own arithmetic. Collision resistance: can anyone find two different inputs with the same digest? Expected strength is half the digest length, so “for an L-bit hash function, the expected security strength for collision resistance is L/2 bits.” Preimage resistance: given a digest, can anyone find an input that produces it? Expected strength is the full L bits. Second preimage resistance: given one input, can anyone find a different one with the same digest? Also L, with a caveat about message length.
| Algorithm | Collision resistance | Preimage resistance | Second preimage |
|---|---|---|---|
| SHA-1 | < 80 | 160 | 105–160 |
| SHA-256 | 128 | 256 | 201–256 |
| SHA-384 | 192 | 384 | 384 |
| SHA-512 | 256 | 512 | 394–512 |
Those are NIST’s figures, and the SHA-1 row is the interesting one. Every other entry is a clean power of two derived from the digest size. SHA-1’s collision column reads “< 80”, and NIST explains the inequality: the halving rule “is currently believed to be true for all the approved hash functions except SHA-1”, whose “latest cryptanalytic results … indicate that it may have a collision resistance strength that is considerably less than its expected strength of 80 bits.”
It stopped being theoretical in 2017. The CWI Amsterdam and Google team behind SHAttered produced two different PDF files with the same SHA-1 digest, and published what it cost: “Producing the collision took roughly nine quintillion SHA-1 computations, the work of about 6,500 CPU-years and 110 GPU-years run in parallel.” Expensive, and limited, because the attacker had to control both documents from the start.
That limitation fell in 2020. Gaëtan Leurent and Thomas Peyrin announced SHA-1 is a Shambles: “We have computed the very first chosen-prefix collision for SHA-1.” A chosen-prefix collision lets an attacker begin from a given prefix, which is what turns a curiosity into a forgery: their paper demonstrates that “PGP keys can be forged if third parties generate SHA-1 key certifications”. The cost was “about 75k USD” of rented GPU time at the time of writing, which they already estimated down to “about 45k USD”, and projected at “less than 10k USD … by 2025”.
NIST drew the line in December 2022: “Today’s more powerful computers can create fraudulent messages that result in the same hash as the original, potentially compromising the authentic message”, and “We recommend that anyone relying on SHA-1 for security migrate to SHA-2 or SHA-3 as soon as possible.” The federal deadline is 31 December 2030.
And yet SHA-1 remains in the menu above, deliberately. Verifying a digest someone published in 2009 is a real task, and the attacks described here do not help an attacker who wants to find an input matching a digest you already hold: that is preimage resistance, which NIST still rates at 160 bits. The rule that follows from the arithmetic rather than from slogans is this. If you control the input and only want to detect accidental change, SHA-1 is adequate. If an adversary can influence the input, or anything is being signed or trusted on the strength of the digest, SHA-1 is unusable and SHA-256 costs you nothing.
This is the most consequential thing on the page, and it is the use people reach for first. These functions are designed to be fast, because integrity checking means hashing gigabytes. Password storage needs the exact opposite property, and NIST SP 800-63B-4 spells out what is required: “Verifiers SHALL store passwords in a form that is resistant to offline attacks. Passwords SHALL be salted and hashed using a suitable password hashing scheme.”
The standard then says why, in a sentence that is really a description of what a plain digest fails to do: password hashing schemes “take a password, a salt, and a cost factor as inputs and generate a password hash. Their purpose is to make each password guess more expensive for an attacker who has obtained a hashed password file, thereby making the cost of a guessing attack high or prohibitive.” The cost factor “SHOULD be as high as practical without negatively impacting verifier performance” and “SHOULD be increased over time to account for increases in computing performance.” The salt “SHALL be at least 32 bits in length and chosen to minimize salt value collisions among stored hashes”.
A bare SHA-256 has no salt, so identical passwords produce identical digests and one precomputed table attacks every account at once. It has no cost factor, so the defender cannot make guessing expensive and hardware improvements work only for the attacker. It has no versioning, so there is no migration path when the work factor needs raising. Every one of those is a requirement in the paragraph above, and a general-purpose hash satisfies none of them. Use the password hashing scheme your platform provides. This page is the wrong tool, and no amount of iterating it in application code makes it the right one.
Verify the tool before trusting it. With SHA-256 selected, abc
should give
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. That is the digest
NIST prints in its own SHA-256 worked example, and if a hash tool disagrees with it, stop using the
tool. An empty input gives
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, which is worth
learning to recognise: it is what you get from a file that turned out to be empty.
Bytes, not characters. The counter reports UTF-8 bytes, and that is the right unit, because hash functions are defined over bytes. It is also the usual reason two people hash “the same” text and get different answers. “café” is four characters and five bytes. “naïve” is five characters and six bytes. A single key emoji is one character and four bytes. If a digest you expect to match does not, check the encoding, then check for a trailing newline, which is the other classic culprit when comparing against a command-line tool.
Small change, total change. abc and abd differ by one
bit of input and their SHA-256 digests differ in 122 of 256 output bits, about the half you would
expect between unrelated values. This is why a digest is a good change detector and a useless
diagnostic: it tells you that two things differ, never how much or where.
Whether the digest you are comparing against is authentic. A matching hash proves the bytes match the digest you were given. It says nothing about whether that digest came from the person you think, and a published checksum sitting on the same compromised server as the download it describes proves nothing at all. That is a signature’s job, not a hash’s.
Files. The box takes text or hex bytes, not a file. Hashing a file in the
browser is possible with the same interface and this page does not do it, so a file checksum still
needs sha256sum, shasum -a 256 or Get-FileHash. What the box
can now do is produce the file’s bytes when you tell it to. A textarea normalises
every line ending to a line feed, so text copied out of a Windows-authored file, a PEM block or a
set of mail headers used to be hashed with its carriage returns already gone, producing a digest
that could never match the file and giving no sign that anything had happened. Setting
Line endings to CRLF restores them. A trailing newline is still yours to get right:
a text box has none unless you type one, and most files end with one.
The same three visible characters, two line endings · digests computed with sha256sum, 4 October 2026
Both are correct digests of what was put in. Only one of them is the digest of the file, and before 4 October 2026 this page could only ever give you the first.
What happens on a page served over plain HTTP. The Web Cryptography API marks
crypto.subtle as available only in a secure context, so on
http:// the browser’s own implementation is simply not there. This page carries
its own SHA-256 for that case. Checked on 2 October 2026 at 601 input lengths from 0 to 600 bytes,
covering every block boundary, that fallback agreed with a reference implementation at every length
and reproduced NIST’s published abc digest. It has one documented limit: its
message-length field is 32 bits, so an input of 536,870,912 bytes or more, which is 512 MiB of text
in a textarea, would be padded wrongly. The other three algorithms refuse rather than guess in that
situation, which is the correct behaviour.
Part of the QuikUtil tools collection. Your text is hashed in your browser and is not transmitted.
crypto.subtle is restricted to secure contexts.
w3c.github.io/webcryptoabc digest quoted above, character for character.
csrc.nist.gov › examples › SHA256.pdfSHA-256 for anything new, which is why it is the preselected option. It gives a 64-character hex digest and, per NIST SP 800-107 Rev. 1, 128 bits of collision resistance and 256 bits of preimage resistance. SHA-384 and SHA-512 are there when something you are interoperating with asks for them. SHA-1 is there only for reading old data, and the next answer explains why.
Because “broken” applies to one property and not the others, and people legitimately need to verify historical SHA-1 digests. It is broken for collision resistance: NIST’s own table gives SHA-1 “< 80” bits there, a real collision was published in 2017 at a cost of “roughly nine quintillion SHA-1 computations”, and a chosen-prefix collision followed in 2020 for about 75,000 US dollars. It is not broken for preimage resistance, which SP 800-107 still puts at 160 bits. So do not sign anything with it, and do not use it where an attacker supplies the content. NIST has set a deadline regardless: federal use ends 31 December 2030.
Two independent reasons. The browser cannot do it: the W3C Web Cryptography API registers exactly “SHA-1”, “SHA-256”, “SHA-384” and “SHA-512” for hashing, and MD5 does not appear anywhere in that specification. And it should not be used for this purpose anyway: RFC 6151 states that “MD5 is no longer acceptable where collision resistance is required such as digital signatures”. The same RFC is more measured about HMAC-MD5, where it says attacks “do not seem to indicate a practical vulnerability”, while still advising new designs against it.
No. These functions are built to be fast, and speed is exactly what you do not want. NIST SP 800-63B-4 requires the opposite: passwords “SHALL be salted and hashed using a suitable password hashing scheme” whose “purpose is to make each password guess more expensive for an attacker who has obtained a hashed password file”, with a cost factor that “SHOULD be as high as practical” and a salt of “at least 32 bits in length”. A bare SHA-256 has no salt and no cost factor, so one GPU tries billions of candidates a second against every account at once.
No. Hashing happens in your browser. On an https:// page it calls the browser’s built-in Web Crypto implementation; on plain http:// that interface is unavailable, because the specification marks crypto.subtle as secure-context only, and the page falls back to a SHA-256 written into the page itself. The other three algorithms will report an error in that situation rather than return a wrong answer.
UTF-8 bytes, not characters, and the difference is the thing that most often makes two people get different digests for what looks like the same text. “café” is four characters and five bytes. A single key emoji is one character and four bytes. Hash functions are defined over bytes, so the encoding is part of the input. The counter reports what was actually hashed rather than what you pasted, which is why the two can differ: choosing CRLF under Line endings adds one byte per line, and setting Input is to hex bytes means the box holds a description of the bytes rather than the bytes themselves.
By design. Changing “abc” to “abd” changes 122 of the 256 output bits, close to the half you would expect from an unrelated value. That is what makes a digest useful for spotting change, and it is also why a digest tells you only that something differs, never what or where.
Yes, against NIST’s own published example. Type abc into the box with SHA-256 selected and you should get ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad, which is the digest printed in NIST’s SHA-256 example document. An empty box gives e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, the digest of the empty message, which is worth recognising because it is what you get when a file you meant to read turned out to be empty.