Hash generators.

The hash generators cover 32 algorithms, each with a text page and a file page. For integrity checks and signatures SHA-256 is the safe default, SHA-512 and SHA-3 give a larger margin, and BLAKE3 is a fast cryptographic option for big files.

Not where an attacker is involved. Collisions in MD5 and SHA-1 can be built on purpose, so neither should sign anything or prove a file wasn't swapped. They are still fine as plain checksums, cache keys and de-duplication, and the tools stay for matching legacy systems.

SHA-256 and SHA-512 are SHA-2, built from a different construction than SHA-3. SHA-3 is Keccak as NIST standardised it in 2015, with changed padding, so its digests differ from the original Keccak's for every input. Ethereum's keccak256 is the original form, which is why the tools have both.

No. A hash is one-way and has no key to decrypt it. What an attacker can do is hash guesses until one matches, which works against short or common inputs and is why passwords need a salted, slow hash instead.

Yes. Each page's toolbar switches between its closest relatives, such as SHA-256 beside SHA-1, SHA-384 and SHA-512, and the digest updates as you switch. The page keeps your input, so the same text or file can be hashed several ways.

No. CRC32, CRC64, Adler-32 and xxHash catch accidental damage and are not built to stop someone who forges a file to match, and none of them takes a key here. Use SHA-256 or BLAKE3 when tampering matters.

CRC32 is what ZIP and PNG use and Adler-32 is what zlib uses, so pick them to match those formats. xxHash is for speed in hash tables and de-duplication, where nobody is attacking the hash.

Seed 0, the reference implementation's default, for xxHash32, xxHash64, xxHash3 and xxHash128. A tool that seeds differently gives a different value for the same input.

CRC-64/XZ, which uses the ECMA-182 polynomial, as xz, Redis and Go's crc64.ECMA do. Other CRC-64 variants have different polynomials and give different values.

The digest generators take files up to 1 GB, and the password hashes up to 64 MB. The browser reads the whole file into memory, so the tool declines anything larger with a message that names the limit.

Hash the file, then paste the published digest into the Verify field. It accepts hex in either case, with spaces, colons or dashes between bytes, a 0x prefix, or Base64 and Base64url, and says whether they match.

Every digest except the CRC and Adler checksums, the xxHash family and double SHA-256. SHA-1, SHA-2, SHA-3, Keccak, MD4, MD5, RIPEMD-160, BLAKE, Whirlpool and SM3 take a secret, read as UTF-8 text, and the output is the standard RFC 2104 HMAC.

The digest is shown as hex, Base64 or Base64url, and the hex can be switched to upper case. Changing the form re-encodes the same digest; it doesn't hash again.

Text is hashed as UTF-8 bytes, and a trailing newline is part of the input. A command-line tool run on a file that ends in a newline hashes one more byte than the box does, so use echo -n or hash the file itself.

No. MD5, SHA-1 and SHA-256 are designed to be fast, so a graphics card can try billions of guesses per second, and they have no salt or cost setting of their own. Use Argon2id or bcrypt instead.

Argon2id, Argon2d and bcrypt. Each run takes a fresh 16-byte random salt and writes one self-describing string with the algorithm, cost, salt and hash in it. A verify field checks a pasted hash against the input.

bcrypt offers costs 10, 11 and 12, with 10 as the default. Argon2 offers 19 MB with 2 passes and 46 MB with 1 pass (both OWASP settings) and 64 MB with 3 passes (RFC 9106), always on one lane, with 19 MB as the default.

Yes. bcrypt ignores everything past byte 72. For longer input the tool hashes the SHA-256 digest of the input in hex instead and says so in the status line, which is the usual workaround.

Because every run draws a new random salt, which is stored inside the string. The same password gives a different hash each time, and the verify field reads the salt back out to check a match.

No. The hashing runs in your browser, and the tool code makes no network request with your input, so a text or a file stays on your machine.

SHA-1, SHA-256, SHA-384, SHA-512 and double SHA-256 use the browser's Web Crypto API. The other algorithms use WebAssembly from the hash-wasm library, imported the first time a digest is asked for.

No. The hash generators work without signing in, and nothing you type is kept after you close the tab.