Instantly compute cryptographic hashes from text or files. All processing happens entirely in your browser - nothing is ever uploaded or transmitted.
| Algorithm | Output Length | Released | Security Level | Common Use Cases |
|---|---|---|---|---|
| MD5 | 128 bits (32 hex chars) | 1992 | Broken | File checksums, non-security deduplication, legacy systems |
| SHA-1 | 160 bits (40 hex chars) | 1995 | Deprecated | Git commit IDs (legacy), older TLS certificates, version control |
| SHA-256 | 256 bits (64 hex chars) | 2001 | Strong | Software verification, TLS/HTTPS, Bitcoin, digital signatures, passwords |
| SHA-512 | 512 bits (128 hex chars) | 2001 | Maximum | High-security applications, database password storage, sensitive file verification |
A cryptographic hash function is a mathematical algorithm that takes any input - a single letter, a full novel, or an entire operating system ISO image - and produces a fixed-length string of characters called a hash, digest, or checksum. The output is always the same length regardless of how large or small the input is. For example, SHA-256 always outputs exactly 64 hexadecimal characters.
Hash functions are designed to be one-way functions: it is computationally trivial to calculate a hash from an input, but it is practically impossible to reconstruct the original input from the hash alone. Think of it like a fingerprint - you can easily take someone's fingerprint, but you cannot reconstruct the person from the fingerprint. This one-way property is the cornerstone of modern cybersecurity.
A critical property is determinism: the exact same input will always produce the exact same output hash, every single time, on any machine in the world. Even changing a single character - altering "Hello" to "hello" - will produce a completely different hash. This sensitivity is called the avalanche effect and is what makes hashes so useful for verifying data integrity.
Hashing and encryption are both cryptographic techniques, but they serve fundamentally different purposes. The most critical distinction is reversibility. Encryption is a two-way process: data is scrambled using a key, and that same (or a related) key can be used to unscramble it and recover the original data exactly. This is essential for things like HTTPS connections, where your browser and a web server need to encrypt and then decrypt messages to each other.
Hashing, by contrast, is a one-way process. There is no key and no "unhashing" operation. You cannot recover the original input from a hash. This makes hashing ideal for scenarios where you need to verify that data is correct or that a password matches, without ever needing to store or transmit the original sensitive data. A secure website does not store your password - it stores the hash of your password. When you log in, it hashes what you type and compares the two hashes. If they match, you are authenticated, and the original password never needed to be stored.
MD5 was designed in 1992 and was considered strong at the time, but researchers have since discovered a fatal flaw: collision vulnerabilities. A collision occurs when two completely different inputs produce the same output hash. In 2004, cryptographers demonstrated that MD5 collisions could be intentionally engineered, meaning an attacker could craft a malicious file that has the identical MD5 hash as a legitimate, trusted file. This completely breaks its trustworthiness as a security primitive.
For password storage, MD5 is doubly dangerous. Beyond collisions, it is extremely fast - which sounds like a good thing but is terrible for passwords. Attackers can use GPU-accelerated brute-force attacks to try billions of MD5 hashes per second. Dedicated hardware can crack short MD5 passwords in seconds. For this use case, you should always use purpose-built slow algorithms like bcrypt, Argon2, or scrypt, which are specifically designed to be computationally expensive.
However, MD5 remains entirely valid for non-security file integrity checks. If you are verifying that a large file downloaded correctly and was not corrupted in transit (rather than tampered with by a malicious actor), MD5 checksums are fast, universally supported, and perfectly sufficient. Many Linux distributions still publish MD5 checksums alongside their ISO images for quick download verification.
A hash collision occurs when two distinct inputs produce an identical output hash. Because hash functions map an infinite input space (any string of any length) to a finite output space (a fixed-length string), it is mathematically guaranteed that collisions must exist in theory. The design goal of a secure hash algorithm is to make finding a collision so computationally difficult that it is impossible in practice with any foreseeable computing resources.
The severity of a collision depends entirely on context. For MD5 and SHA-1, practical collision attacks have been demonstrated. In 2017, Google's Project Zero team published "SHAttered" - the first publicly known SHA-1 collision, producing two different PDF files with the identical SHA-1 hash. This type of attack could theoretically be used to forge digital signatures, allowing a malicious document to inherit the valid certificate of a trusted one.
For SHA-256 and SHA-512, no collisions have ever been found. The sheer size of their output space (2^256 and 2^512 possible values respectively) makes a collision attack computationally infeasible. Even if every computer ever built worked in unison for billions of years, they would not crack a SHA-256 hash through brute force. This is why SHA-256 is the standard for software signing, SSL certificates, and the Bitcoin blockchain.
When a software developer or organization publishes a new release - an OS installer, a firmware update, or a security tool - they run the final binary file through SHA-256 and publish the resulting 64-character hash string alongside the download link on their official website. This published hash is called the checksum or hash digest.
When you download the file, you can use a tool like this one to compute the SHA-256 hash of your downloaded file. You then compare your computed hash against the official hash published on the developer's website. If the two strings match exactly - character for character - it proves two things: first, that your file is complete and was not corrupted or truncated during the download. Second, and more importantly, it proves the file has not been tampered with - no malicious actor intercepted the download and injected malware into it.
This verification workflow is the backbone of secure software distribution and is why major projects like Ubuntu Linux, OpenSSL, and the Tor Browser publish SHA-256 checksums for every single release. It is a simple, one-step way to establish a chain of trust between the developer's build server and your local machine, without requiring a direct secure connection to the source.