A cryptographic hash function takes any input , a text string, a file, a binary blob , and produces a fixed-length string of characters called a hash, digest, or checksum. The key properties that make this useful:

• Deterministic , the same input always produces the same hash
• Fixed output length , regardless of how large the input is, SHA-256 always produces a 256-bit (64-character hex) string
• Avalanche effect , changing even one character in the input produces a completely different hash
• One-way , given a hash, it's computationally infeasible to reconstruct the original input
• Collision resistant , it's computationally infeasible to find two different inputs that produce the same hash

These properties together make hashes function as digital fingerprints.

Each algorithm has a different trade-off between speed and security:

MD5 (128-bit output) Fast and widely supported, but cryptographically broken , known collision vulnerabilities mean two different files can hash to the same value. Don't use it for anything security-sensitive. Still acceptable for non-security uses like cache invalidation.

SHA-1 (160-bit output) Deprecated for cryptographic use since Google demonstrated a practical collision attack in 2017. Still found in legacy systems. Avoid for new implementations.

SHA-256 (256-bit output) The current standard for most security applications , TLS certificates, Bitcoin, code signing, modern authentication systems. Use this as your default.

SHA-512 (512-bit output) Stronger than SHA-256 with a larger output. Marginally slower on 32-bit systems but faster on 64-bit hardware. Good for highest-security scenarios.

File integrity verification is one of the most practical everyday uses of hashing. When you download software, an OS image, or any critical file, the publisher typically provides a checksum:

1. Download the file and note the checksum on the download page (usually SHA-256)
2. Upload the file to the hash generator
3. Select the matching algorithm
4. Compare the generated hash character-by-character against the publisher's hash

If they match exactly, the file is intact and untampered. If they differ by even one character, the file has been modified , whether through a download error, network corruption, or something more deliberate.

Databases should never store passwords in plain text. Instead, they store a hash of the password (combined with a random value called a salt). When you log in:

1. You submit your password
2. The server hashes your input using the same algorithm and salt stored with your account
3. It compares the result to the stored hash
4. If they match, authentication succeeds , the server never needed to know your actual password

This means if a database is breached, attackers get hashes, not passwords. For modern password storage, use bcrypt, scrypt, or Argon2 rather than raw SHA-256 , these are designed to be slow and computationally expensive, making brute-force attacks much harder.

These terms get used interchangeably but describe completely different operations:

Hashing:

• One-way , you cannot reverse a hash to recover the input
• No key required
• Same input always produces the same output
• Used for: integrity checks, password storage, digital signatures, content addressing

Encryption:

• Two-way , data can be decrypted with the correct key
• Requires a key (symmetric or asymmetric)
• Used for: confidentiality, secure data transmission, protecting sensitive data at rest

Never use hashing to keep data confidential , a hash proves integrity but reveals nothing about the original content. For confidentiality, use AES-256 (symmetric) or RSA/ECC (asymmetric).