Online Hash Calculator

What is a cryptographic hash function?

A cryptographic hash function takes an input of any size and produces a fixed-length digest. Three properties define it: determinism (same input always gives the same output), pre-image resistance (you cannot reverse the hash to recover the input), and collision resistance (it is computationally infeasible to find two different inputs that produce the same digest).

Which algorithm should I choose?

SHA-256 is the right default for almost all general-purpose hashing — universally supported, well-studied, and fast. Use SHA-384 or SHA-512 when a compliance requirement mandates a wider digest. Use Keccak-256 for Ethereum and EVM-compatible chains. Use SHA3-256 as a modern alternative to SHA-256 that is immune to length-extension attacks. Use RIPEMD-160 for Bitcoin addresses or OpenPGP. Use xxHash3 for high-throughput non-cryptographic checksums.

Are these hashes safe for passwords?

No. All algorithms on this tool are designed to be fast, which is harmful for password storage — a fast hash lets attackers brute-force millions of candidates per second. For passwords, use a purpose-built slow algorithm: bcrypt, scrypt, or Argon2, all of which incorporate salting and adjustable work factors.

How does Hashly ensure privacy?

All hashing runs entirely inside your browser. Most algorithms use hash-wasm by Daninet, a WebAssembly library that runs locally without any network calls. MD2 uses a custom inlined implementation of RFC 1319. RIPEMD variants use crypto-api by nf404. No text, no file content, and no hash output is ever transmitted to any server. You can verify this by running the tool while offline — it works identically.

What output formats are available?

Hex (lowercase hexadecimal) is the most common format used in tooling and documentation. HEX is the same in uppercase. Base64 encodes the raw digest bytes as a compact string using the standard Base64 alphabet — note that the + and / characters are not URL-safe and require percent-encoding when embedded in a URL; use hex instead if URL embedding is needed. Binary shows each byte's individual bits, useful for educational and low-level inspection purposes.

What is MD2?

MD2 (Message Digest 2) was designed by Ronald Rivest in 1989, originally for systems with limited resources such as 8-bit machines. It produces a 128-bit (16-byte) digest, displayed as a 32-character hex string. MD2 is the slowest of the MD family and is considered cryptographically broken — pre-image attacks have been demonstrated. It has no practical use in new systems.

What is MD4?

MD4 was also designed by Rivest in 1990 as a faster successor to MD2, targeting 32-bit machines. It produces a 128-bit digest and introduced design ideas later adopted by MD5, SHA-1, and RIPEMD. MD4 was found to be weak very quickly: full collision attacks exist, and it was deprecated by Rivest himself shortly after MD5 was published. It should not be used for any security purpose.

What is MD5?

MD5 (Message Digest 5) was designed by Rivest in 1991 as a more secure replacement for MD4. It produces a 128-bit digest and was the dominant hash function for file integrity and digital signatures throughout the 1990s–2000s. MD5 is cryptographically broken for collision resistance — practical collisions can be computed in seconds. It remains widely acceptable for non-adversarial integrity checks such as download checksums.

Variant comparison

Which variant should I use?

None of the MD variants are suitable for any security-sensitive context. If you need a 128-bit hash for a non-adversarial purpose and MD5 is required for legacy interoperability, MD5 is the only reasonable choice of the three — it has the widest tooling support. Prefer SHA-256 for any new work.

What is SHA-1?

SHA-1 (Secure Hash Algorithm 1) was designed by the NSA and published by NIST in 1995 as the successor to SHA-0. It produces a 160-bit (20-byte) digest, typically shown as a 40-character hex string. For many years it was the dominant hash function in TLS certificates, code signing, and version control systems — Git still uses SHA-1 internally for object addressing.

Is SHA-1 still secure?

SHA-1 is cryptographically broken for collision resistance. In 2017, Google's SHAttered project demonstrated the first practical SHA-1 collision: two distinct PDF files with the same SHA-1 digest. The attack required roughly 6,500 CPU-years of computation, making it expensive but feasible for well-resourced adversaries. NIST formally deprecated SHA-1 for digital signatures in 2011 and disallowed it entirely from 2030 onwards.

When is SHA-1 still acceptable?

SHA-1 remains acceptable for non-security-critical checksums where collision resistance is not required — for example, detecting accidental file corruption, cache invalidation keys, or legacy system interoperability where migration is not yet possible. It should never be used for digital signatures, certificate fingerprints, or any context where an adversary could benefit from crafting a collision.

What is the SHA-2 family?

SHA-2 is a family of hash functions designed by the NSA and published by NIST in 2001, sharing the same Merkle–Damgård construction but differing in internal word size, number of rounds, and output length. All four variants — SHA-224, SHA-256, SHA-384, and SHA-512 — are currently considered cryptographically secure with no known practical attacks on collision or pre-image resistance.

Variant comparison

Which SHA-2 variant should I use?

SHA-256 is the right default for almost everything: universally supported, well-studied, and produces a digest small enough to be practical. Use SHA-384 or SHA-512 when a standard or compliance requirement mandates a larger digest (e.g. FIPS 186-5 for digital signatures) or when you are operating on a 64-bit platform where SHA-512's wider internal word size may be faster. SHA-224 is a truncated form of SHA-256 used only when digest length is constrained.

Can SHA-2 be reversed or cracked?

SHA-2 is a one-way function with no known mathematical inverse. No practical pre-image or collision attack has been demonstrated against any SHA-2 variant. For short or common inputs, precomputed rainbow tables could theoretically recover the original value — salt your data if that is a concern.

What is Keccak?

Keccak is a family of cryptographic hash functions designed by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche. It won the NIST hash function competition in 2012 and became the basis for SHA-3. Unlike earlier designs such as MD5 or SHA-1, Keccak uses a sponge construction built on the Keccak-f permutation — a fundamentally different approach that avoids the Merkle–Damgård length-extension weakness. The four standard variants are Keccak-224, Keccak-256, Keccak-384, and Keccak-512.

What is Keccak-256?

Keccak-256 is the most widely deployed member of the Keccak family, producing a 256-bit (32-byte) digest represented as a 64-character hex string. It is the hash function used natively by Ethereum for address derivation, transaction signing, block header commitments, and Solidity's built-in keccak256() opcode. Importantly, Keccak-256 and SHA3-256 are not identical: Keccak uses a 0x01 padding suffix while NIST SHA-3 uses 0x06, producing different outputs for the same input.

Variant comparison

Which variant should I use?

Keccak-256 is the right default for almost all applications and the only choice for Ethereum compatibility. Keccak-384 and Keccak-512 offer wider digests and higher capacity for security-sensitive contexts. Keccak-224 should only be chosen in environments where a smaller digest size is a strict requirement. If SHA-3 compatibility is required instead of Ethereum compatibility, use the SHA-3 family.

What is SHA-3?

SHA-3 (Secure Hash Algorithm 3) is a family of cryptographic hash functions standardised by NIST in 2015 under FIPS 202. It is based on Keccak, which won the NIST hash function competition in 2012. Unlike SHA-2, SHA-3 uses a sponge construction built on the Keccak-f[1600] permutation — a fundamentally different approach that avoids the Merkle–Damgård length-extension weakness present in SHA-2. The four standard variants are SHA3-224, SHA3-256, SHA3-384, and SHA3-512.

What is SHA3-256?

SHA3-256 is the most widely used member of the SHA-3 family, producing a 256-bit (32-byte) digest represented as a 64-character hex string. It is the recommended modern alternative to SHA-256 when resistance to length-extension attacks is required. Importantly, SHA3-256 and Keccak-256 are not the same — they differ in padding suffix (0x06 vs 0x01), producing different outputs for the same input.

Variant comparison

Which variant should I use?

SHA3-256 is the right default for almost all applications — it offers a strong security level, wide tooling support, and is the most recognisable member of the family. SHA3-384 and SHA3-512 provide wider digests and higher capacity for security-sensitive contexts. SHA3-224 should only be chosen in environments where a smaller digest size is a strict requirement.

What is RIPEMD?

RIPEMD (RACE Integrity Primitives Evaluation Message Digest) is a family of cryptographic hash functions developed in the mid-1990s by Hans Dobbertin, Antoon Bosselaers, and Bart Preneel at KU Leuven, as part of the EU-funded RACE project. The strengthened variants — RIPEMD-128, RIPEMD-160, RIPEMD-256, and RIPEMD-320 — were published in 1996. Unlike the NIST SHA family, RIPEMD was designed independently in Europe and has never been subject to NIST deprecation timelines.

What is RIPEMD-160?

RIPEMD-160 is the most widely deployed member of the RIPEMD family, producing a 160-bit (20-byte) digest typically represented as a 40-character hex string. It uses a dual parallel pipeline design on a Merkle–Damgård construction — two independent computation paths that merge at each compression step, hardening it against the differential attacks that broke MD4 and the original RIPEMD. Bitcoin address generation applies RIPEMD-160 to a SHA-256 digest of the public key (the HASH160 operation). OpenPGP (RFC 4880) also supports RIPEMD-160 for key fingerprints and message signatures.

Variant comparison

Which variant should I use?

RIPEMD-160 is the right default for almost all applications. It is the most studied, most widely deployed, and has the best library and tooling support of the four. RIPEMD-320 offers no security advantage over RIPEMD-160 — it only provides a wider output — but may be useful when a longer digest is a protocol requirement. Similarly, RIPEMD-256 extends RIPEMD-128 without strengthening it. RIPEMD-128 should only be chosen in environments where a 128-bit digest is strictly required and MD5 is undesirable.

What is xxHash?

xxHash is a family of extremely fast non-cryptographic hash functions created by Yann Collet — also the author of Zstandard. It is designed to hash data at near-memory-bandwidth speeds, making it suitable for hash tables, data deduplication, cache keying, and non-adversarial integrity checks. All four variants are deterministic and produce consistent checksums across platforms.

Is xxHash cryptographically secure?

No. xxHash is explicitly not a cryptographic hash function. It provides no pre-image resistance and no collision resistance against adversarial inputs — an attacker with knowledge of the algorithm can craft inputs that produce any desired output. For any use case where integrity must hold against a malicious party, use a cryptographic hash such as SHA-256 or SHA3-256. For passwords specifically, use bcrypt, scrypt, or Argon2.

What is xxHash64?

xxHash64 is the original 64-bit member of the xxHash family, released in 2012. It produces a 64-bit (8-byte) digest represented as a 16-character hex string. It is the most widely deployed xxHash variant in production systems, used by RocksDB, ClickHouse, DuckDB, Zstandard, and Buck2.

Variant comparison

Which variant should I use?

For new projects on modern hardware, xxHash3 is the recommended choice — it is faster than xxHash64, especially for short inputs, and benefits from SIMD acceleration. Use xxHash64 when integrating with existing systems that already depend on it. Choose xxHash128 when a wider 128-bit digest is needed to reduce birthday-bound collision probability at very large scales. Use xxHash32 only when constrained to a 32-bit platform or legacy tooling.