A cryptographic hash function converts input data into a fixed-size digest. The same input produces the same digest, while a small input change should produce a very different result. Hashes are useful for integrity checks, digital signatures, content addressing, and many security protocols.
Use the QuickToolsBox Hash Generator to compare SHA output for sample text in your browser.
The main differences
SHA-1 produces a 160-bit digest and is no longer considered collision-resistant for security-sensitive uses. SHA-256 produces 256 bits and belongs to the SHA-2 family. SHA-512 also belongs to SHA-2 and produces a 512-bit digest.
Longer output does not automatically make every application safer. The protocol, key handling, implementation, and threat model are just as important.
What a hash can prove
If a trusted source publishes the SHA-256 digest of a file, you can hash your downloaded copy and compare the values. A match is strong evidence that the bytes are identical to the bytes used for the published digest.
However, a checksum downloaded from the same compromised location as the file does not prove authenticity. An attacker may replace both. Signed release metadata or a digest obtained through an independent trusted channel provides stronger assurance.
SHA-1
SHA-1 remains visible in old systems, identifiers, and compatibility workflows. Practical collision attacks mean it should not be chosen for new digital-signature, certificate, or adversarial integrity designs.
An existing SHA-1 value may still be useful as a non-security identifier, but its limitations should be explicit. Migrating security-sensitive workflows to a modern algorithm is the safer approach.
SHA-256
SHA-256 is widely supported and is a common default for file integrity, signatures, and general cryptographic protocols. It balances broad compatibility, strong security properties, and compact output.
For most new checksum workflows, SHA-256 is a sensible choice unless a standard or protocol specifies something else.
SHA-512
SHA-512 produces a longer digest and can be efficient on 64-bit processors. Some systems use SHA-512 or related variants because a protocol requires them or because their performance characteristics are favorable.
Do not truncate or transform a digest unless the protocol defines exactly how to do so.
Hashing is not encryption
Encryption is designed to be reversible with a key. Hashing is designed as a one-way operation. A digest cannot normally be decoded to reveal the original input, but attackers can guess inputs and compare their hashes.
This distinction is especially important for passwords.
Do not store passwords with plain SHA
Fast general-purpose hashes make large guessing attacks inexpensive. Password storage should use a dedicated password-hashing function such as Argon2id, scrypt, bcrypt, or PBKDF2 with appropriate parameters and a unique salt.
Adding a salt prevents identical passwords from automatically producing identical stored values and makes precomputed lookup tables less useful. The work factor makes each guess more expensive.
Common hashing mistakes
- Hashing text in different character encodings
- Comparing uppercase and lowercase hexadecimal strings incorrectly
- Accidentally including a trailing newline
- Treating an untrusted checksum as proof of authenticity
- Using SHA-1 for a new security design
- Using a fast hash alone for password storage
Frequently asked questions
Why do two tools produce different hashes for text that looks identical?
The bytes may differ because of character encoding, line endings, invisible spaces, Unicode normalization, or a trailing newline.
Can two inputs have the same hash?
Yes, because infinitely many possible inputs map to a finite output space. A secure hash makes it computationally infeasible to find a useful collision.
Should I choose SHA-512 because the number is larger?
Not automatically. Use the algorithm required by the protocol or a well-supported modern default such as SHA-256. Security depends on the complete design.