Hash Generator (SHA-256, SHA-512)
Compute SHA-1, SHA-256, SHA-384, and SHA-512 hashes.
Hashed in your browser, input never sentGenerate a SHA-256 hash from text
About this SHA hash generator
A hash is a fixed-length fingerprint of data. The same input always produces the same output, changing a single bit produces a completely different output, and the length never varies — SHA-256 returns 64 hexadecimal characters whether you hash one letter or a 4 GB disk image. Hashes are used to verify integrity, to compare values without storing them, and to give a piece of content a stable name.
This tool computes all four SHA variants at once, updating as you type, using the Web Crypto API built into your browser — the same audited implementation your browser uses for HTTPS, not a JavaScript reimplementation. Your input never leaves your device, so it is safe to hash values you would not paste into a tool that runs on someone else’s server.
The four algorithms offered here are what browsers expose, not the whole family. FIPS 180-4 defines SHA-1 plus six SHA-2 variants (SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256); Web Crypto implements SHA-1, SHA-256, SHA-384 and SHA-512 and nothing else, which is also why there is no MD5 and no SHA-3 on this page. SHA-256 works on 32-bit words with a 512-bit block; SHA-384 and SHA-512 work on 64-bit words with a 1024-bit block. SHA-384 is SHA-512 truncated, and that truncation matters: truncated SHA-2 variants resist length-extension attacks, while SHA-1, SHA-256 and SHA-512 do not.
Input encoding is part of the hash, and it is where most "my checksums don’t match" reports come from. This tool encodes your text as UTF-8 before hashing, so the same visible characters saved as UTF-16 or Latin-1 hash differently. An invisible trailing newline — which most editors add on save — changes every byte of the digest, and so does one capital letter. If you are checking a download against a published checksum, hash the file itself rather than text you retyped.
The one thing you should not do with these is store passwords. SHA is designed to be fast, and fast is exactly wrong when an attacker has your database and is guessing. NIST SP 800-63B requires passwords to be salted with at least 32 bits and run through a password hashing scheme whose cost factor is as high as practical — in practice bcrypt, scrypt, Argon2 or PBKDF2, not a bare SHA. Likewise, do not authenticate a message with SHA(secret + message); use HMAC, which is built to resist the length-extension problem above. And SHA-1 should not be used for anything security-relevant: a practical collision was published in 2017, and NIST is retiring SHA-1 for security use by December 31, 2030.
SHA algorithms compared, and how to hash a file on your own machine
Picking an algorithm is usually a two-second decision — SHA-256 unless something tells you otherwise — but it helps to know what the others are for. Collision resistance is roughly half the output length, so SHA-256 offers about 128 bits of collision resistance and SHA-512 about 256.
| Algorithm | Output | Status and typical use |
|---|---|---|
| SHA-1 | 160 bits / 40 hex | Broken: a practical collision was published in 2017. NIST retires it for security use by Dec 31, 2030. Still fine as a non-security identifier, e.g. Git object IDs. |
| SHA-256 | 256 bits / 64 hex | The default. TLS certificates, package and release checksums, content addressing. |
| SHA-384 | 384 bits / 96 hex | SHA-512 truncated. Resists length extension; common in TLS cipher suites. |
| SHA-512 | 512 bits / 128 hex | Larger margin, 64-bit internals. Used where a longer digest is specified. |
| MD5 | 128 bits / 32 hex | Collisions are trivial to produce. Not available in Web Crypto. Legacy checksums only. |
| SHA-3-256 | 256 bits / 64 hex | Different construction (Keccak), no length-extension weakness. Not in Web Crypto — use a local tool. |
This tool hashes text, not files — the field above takes a string. To check a download, hash it where it already lives, with a command your operating system ships:
| System | Command |
|---|---|
| Windows (cmd) | certutil -hashfile file.iso SHA256 |
| Windows PowerShell | Get-FileHash file.iso -Algorithm SHA256 |
| macOS | shasum -a 256 file.iso |
| Linux | sha256sum file.iso |
Then compare. Hex digests are case-insensitive, so uppercase output from certutil and lowercase output from sha256sum are the same value; certutil also inserts spaces you should ignore. The comparison is only meaningful if the published checksum comes from somewhere an attacker could not edit alongside the file. A checksum sitting on the same page as the download proves the transfer was not corrupted — it does not prove the file is genuine. A signature is what proves authenticity.
SHA-256("hello") 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
SHA-256("Hello") 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969
SHA-256("hello\n") 5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03Two things a hash cannot do. It cannot be reversed — but that is not the same as keeping a value secret, because a short or predictable input can simply be guessed and hashed until the digests match. Hashing an email address does not anonymise it. And an unkeyed hash proves nothing about who produced the data: whoever can change the file can change the published hash too. For that you need a MAC or a digital signature.
Reference tables
FAQ
Which SHA should I use?
SHA-256 is the standard choice for most purposes. SHA-1 is broken for security and should only be used for legacy compatibility (like Git object IDs).
Why no MD5?
MD5 is cryptographically broken and browsers don’t implement it natively. If you need it for a legacy checksum, dedicated tools exist, but avoid it for anything new.
Can a hash be reversed?
No — hashing is one-way. But common inputs can be guessed by brute force, which is why passwords need salted, slow hashes (bcrypt, Argon2), not plain SHA.