Hash Calculator | CRC-8
Input Data | Text
No file selected
| Name | # Bits |
|---|---|
| CRC-8 | 8 |
| CRC-16 | 16 |
| CRC-32 | 32 |
| Name | # Bits |
|---|---|
| MD5 | 128 |
| RIPEMD-160 | 160 |
| SHA-1 | 160 |
| SHA2-224 | 224 |
| SHA2-256 | 256 |
| SHA2-384 | 384 |
| SHA2-512 | 512 |
| SHA3-224 | 224 |
| SHA3-256 | 256 |
| SHA3-384 | 384 |
| SHA3-512 | 512 |
A hash function takes input of any size and produces a fixed-length string of characters — the hash, or digest. Hash "hello" with SHA-256 and you get 64 hexadecimal characters. Hash an entire film with the same algorithm and you still get 64 characters. The output looks random but is completely deterministic: the same input always produces the same hash, on any machine, in any programming language, forever.
Two other properties make hashes useful. They are one-way — given a hash, there is no practical way to recover the original input. And a good hash function has the avalanche property : change a single character of the input and roughly half the output bits flip. There is no partial similarity, so you cannot tell from two hashes whether their inputs were nearly identical.
The two groups in the table above serve genuinely different purposes, and confusing them is a real mistake.
CRC stands for Cyclic Redundancy Check. These are designed to catch accidental corruption — a flipped bit from a bad cable, a truncated download, a scratched disc. They are fast and short, and they are used in Ethernet frames, ZIP archives, and PNG files. They are not secure: forging a different input with the same CRC is trivial, so never use one to verify that a file has not been tampered with deliberately.
These are built so that finding two inputs with the same hash is computationally infeasible. That makes them suitable for verifying downloads against a published digest, storing password verifiers, generating content addresses, and signing data.
Hashing passwords with a plain function like SHA-256 is not secure, even though it is a strong algorithm. The problem is speed: SHA-256 is designed to be fast, so an attacker with a stolen database can test billions of candidate passwords per second on a GPU.
Password storage needs a deliberately slow algorithm with a per-user random salt — bcrypt, scrypt, or Argon2. Use this tool to understand and inspect hashes, and to verify file integrity, but use a purpose-built password hashing library for credentials.
Not directly. Hash functions discard information, so there is no inverse to compute. What is possible is guessing: an attacker hashes likely inputs and compares. Short or common inputs fall quickly to this, which is why salting matters for passwords. Long, unpredictable inputs are effectively safe.
That is a collision. Because inputs are unlimited and outputs are fixed length, collisions must exist mathematically — but for a sound algorithm like SHA-256, finding one is computationally out of reach. For MD5 and SHA-1, collisions have been produced deliberately, which is precisely why they are no longer trusted.
Yes, and this is the whole point. Hashing is deterministic and standardized, so SHA-256 of a given file is identical here, on your command line, and on a server on the other side of the world. That is what makes published checksums verifiable.
By design. The avalanche property means a one-bit change to the input flips about half the output bits. Without it, an attacker could learn about the input by observing how similar two hashes were.
No. Hashing happens entirely in your browser, including for files — the file is read locally and never transmitted. You can safely hash sensitive documents, and the tool keeps working with your network disconnected.
The website uses cookies for essential functionality. With your consent, we also use them for analytics, personalization, and personalized ads. Ads are shown either way — without consent they are non-personalized.