Developer Tools — 9 tools

Hash Generator

Generate SHA-1, SHA-256, SHA-384, and SHA-512 hashes from text or a file. Everything runs in your browser with the Web Crypto API — nothing is uploaded, so it is safe for tokens, passwords, and private files.

Algorithms

 

Or hash a file

What is a cryptographic hash?

A cryptographic hash takes an input of any size and returns a fixed-length hexadecimal digest: SHA-256 always returns 64 characters, SHA-512 always 128, regardless of whether you hashed a single letter or a 4 GB video. Two properties make it useful. First, it is deterministic — the same input always gives the same digest. Second, it is effectively one-way and collision-resistant: you cannot work backwards from the digest, and finding two different inputs with the same digest is impractical. Change one character in the input and roughly half the bits in the output flip, so there is no gradual "close enough" match. The SHA-1 and SHA-2 algorithms used here are specified by NIST in FIPS 180-4.

SHA-256 vs SHA-1 vs SHA-384 and SHA-512

SHA-256 is the default choice for almost everything: file verification, signatures, blockchains, and content addressing. SHA-1 is legacy and cryptographically broken — collisions have been demonstrated — so use it only where a system you do not control demands it. SHA-384 and SHA-512 belong to the same family and produce longer digests; they are used in some government and enterprise standards and are fine for interoperability, but for new work SHA-256 is the default that virtually every tool and published checksum expects. (On 64-bit processors SHA-512 is often actually the faster of the two, so speed is not a reason to avoid it.)

How to check a downloaded file's checksum

Publishers often list a SHA-256 checksum next to a download. Hash the file here, copy the digest, and compare it with the published value. Matching exactly means the file is byte-for-byte identical; even a single flipped bit from a failed download changes the hash completely. This is the same verification package managers and operating-system installers perform internally, and it is the honest way to check a download you are not sure about — far more reliable than eyeballing the file size.

Hashing vs encryption vs encoding

These three get mixed up constantly. Hashing is one-way and produces a fingerprint — you cannot recover the input. Encryption is two-way and requires a key, so encrypted data can be decrypted when needed. Encoding (like Base64) is not protection at all: it is a reversible text representation of the same bytes. If you need to inspect a token rather than fingerprint it, the JWT decoder shows the header and payload claims; if you need to generate random values rather than verify them, the UUID generator is the right tool.

Frequently asked questions

What is a hash function used for?

A hash function turns any input — text or a file — into a fixed-length fingerprint. The same input always produces the same hash, but changing even one character produces a completely different one. That makes hashes useful for checking that a download arrived intact, comparing two files without opening them, storing passwords safely (as a hash plus salt), and giving content a stable ID.

Can a hash be reversed?

No. Hashing is a one-way operation by design — there is no key and no way to compute the original input from the digest. The only practical attack is guessing inputs and hashing them to see if they match, which is why password hashing uses slow algorithms (bcrypt, argon2) and a random salt, not a single fast SHA pass.

Should I use SHA-256 or SHA-1?

Use SHA-256 or stronger for anything security-related. SHA-1 is cryptographically broken — practical collisions have been demonstrated — so it is only acceptable for legacy checksums and non-security identifiers. SHA-384 and SHA-512 are available here for compatibility with systems that expect them; they are slower but offer a larger digest.

Is hashing the same as encryption?

No. Encryption is reversible with the right key; hashing is not reversible at all. Encrypt data when you need to read it later; hash data when you only need to verify or compare it. A common mistake is calling Base64 encoding "encryption" — it is not even hashing, just a reversible text representation.

How do I verify a file hash?

Drop the file onto the tool, copy the SHA-256 value it produces, and compare it character by character with the checksum published by the source. If the two match exactly, the file is byte-for-byte the one the publisher intended. Anything that altered the file — even a corrupted byte from a bad download — changes the hash completely.

Is my text or file uploaded?

No. Hashing uses the browser's built-in Web Crypto API and never leaves your device, so it is safe for sensitive text, tokens, and private files. That is a meaningful difference from server-side hash tools, where you would be uploading the very data you are trying to protect.