Hashing vs Encryption: What's the Difference?

Hashing vs encryption: the core difference

Hashing and encryption both protect data with math, but they solve different problems. Encryption is reversible: it turns readable data into ciphertext that the correct key converts back to the original. Hashing is one-way: it produces a fixed-length digest that cannot be reversed to reveal the input. Use encryption when you need the data back later, such as a stored tax return. Use hashing when you only need to confirm data matches a known value, such as verifying a password without storing it.

Getting this wrong is one of the most common and costly mistakes in applied security. The 2012 LinkedIn breach exposed roughly 6.5 million password hashes stored as unsalted SHA-1, a fast algorithm never meant for passwords, and attackers cracked them within hours. The 2022 LastPass incident showed the other side: attackers copied encrypted vault data, but the plaintext stayed out of reach without each user's decryption key. According to the IBM Cost of a Data Breach Report 2024, the global average breach cost reached $4.88 million, so the price of choosing the wrong method is not theoretical.

NIST cryptographic standards treat these as complementary tools: encryption for data that must be retrieved (financial records, communications, tax documents) and hashing for verification and authentication (password storage, file integrity, digital signatures). They are not interchangeable.

What encryption is and how it works

Encryption transforms readable plaintext into unreadable ciphertext using an algorithm and a cryptographic key, and the same key material reverses the process. That reversibility is the whole point: it protects data you still need to open later.

Two modes cover most uses. Symmetric encryption uses one shared key for both directions; AES-256, recommended by NIST, is the standard for data at rest and is considered infeasible to brute-force with current computing. Asymmetric encryption uses a linked public and private key pair; RSA and Elliptic Curve Cryptography (ECC) secure key exchange and digital signatures, and because they are slower, they usually protect a symmetric session key rather than bulk data.

Reach for encryption when data must be retrieved: customer records, financial transactions, patient information, backups, and traffic in transit. HIPAA, PCI DSS 4.0, and the FTC Safeguards Rule all require encryption for specific data categories, with documented justification when it is not used.

What hashing is and how it differs

Hashing converts input of any size into a fixed-length string, called a digest, using a one-way function. A cryptographic hash cannot be reversed to reveal the original input, which is exactly why it suits verification and authentication rather than protecting data you need to read back.

Four properties define a cryptographic hash function:

• Deterministic: the same input always yields the same digest.
• Avalanche effect: changing a single character produces a completely different digest, so tampering is easy to spot.
• Collision resistance: it should be infeasible for two different inputs to produce the same digest.
• One-way: recovering the input from the digest is impractical by design, because there is no decryption step.

MD5 and SHA-1 were once standard and are now considered cryptographically broken because of demonstrated collision attacks. The OWASP Password Storage Cheat Sheet and NIST guidance point to SHA-256, SHA-3, or purpose-built password hashing algorithms for security-relevant work.

Password hashing and salting

Password storage is the most important and most mishandled use of hashing. Never store passwords in plaintext or with reversible encryption; both have caused breaches exposing millions of credentials. General-purpose hashes like SHA-256 are built for speed, and modern GPUs compute billions of them per second, so they are the wrong choice for passwords.

Use a slow, purpose-built password hashing algorithm instead. bcrypt has been dependable since 1999 and offers a tunable work factor. Argon2 won the 2015 Password Hashing Competition and resists GPU and ASIC attacks, and NIST points to Argon2id for new systems. scrypt is memory-hard and used in high-security settings. A salt is a unique random value added to each password before hashing; without it, identical passwords produce identical digests that attackers crack in bulk with precomputed rainbow tables. With a unique salt per user, each password has to be attacked on its own.

File integrity verification in practice

Hashing is also the standard way to detect unauthorized file changes. Software vendors publish a SHA-256 hash next to a download so you can confirm the file was not altered in transit; running the hash locally and comparing values takes seconds. Security teams use File Integrity Monitoring (FIM), which continuously hashes system files and alerts when a digest changes unexpectedly. The MITRE ATT&CK framework references this as a detection control for persistence and defense-evasion tactics. Building the same hash check into backups confirms restored data matches its pre-backup state, ruling out corruption or tampering during storage.

Where hashing and encryption work together

Most mature systems use both. When your browser opens an HTTPS connection, asymmetric encryption (RSA or ECC) exchanges a session key, symmetric AES-256 protects the traffic, and HMAC-SHA256 confirms messages were not tampered with. Certificate checks use hashing to validate the server's signature. Digital signatures combine the two directly: you hash a document, encrypt that hash with your private key, and a recipient decrypts it with your public key and re-hashes the document. Matching results prove the document is unaltered and came from you, and hashing it first keeps the process fast while providing non-repudiation.

One warning: encoding is not security. Base64 turns binary data into text for transmission and is instantly reversible with no key. CISA guidance treats mistaking encoding for encryption as a source of false confidence that leaves data exposed. Put that point in security awareness training so staff understand that encoded URLs, attachments, or data files offer no real protection against a determined attacker.

Choosing the right method

Ask one question: does this data need to be retrieved in its original form? If yes, encrypt it. If you only need to confirm that a value matches a known one, hash it.

Use hashing to store passwords (salted, with bcrypt, Argon2id, or scrypt), verify file integrity, fingerprint documents, and build authentication or digital signatures that never recover the original value. Use encryption to protect data you retrieve later (customer records, financial and tax data), secure transmission over HTTPS and VPNs, protect backups and cloud storage, and meet confidentiality rules under HIPAA, PCI DSS 4.0, and GDPR. Across every framework the technical baseline is consistent: AES-256 or equivalent for encryption, bcrypt or Argon2id for passwords, no MD5, SHA-1, or DES, and documented cryptographic controls. If you want the model behind these choices, our guide to the CIA triad shows how confidentiality and integrity map to each method.

Compliance requirements across regulated industries

Tax professionals under IRS Publication 4557 and the FTC Safeguards Rule must encrypt taxpayer data at rest and in transit and document those controls in a Written Information Security Plan (WISP), which the IRS expects firms to maintain and update annually. Password hashing standards apply to any system holding practitioner or client credentials. See our IRS WISP requirements guide and FTC Safeguards recordkeeping guide for what to document.

Healthcare organizations under the HIPAA Security Rule must address encryption for electronic protected health information under §164.312, with written justification for any addressable specification they do not deploy. Practices can review gaps with our HIPAA guidance for dental and specialty offices and plan recovery with ransomware protection. Financial services firms under PCI DSS 4.0 must encrypt cardholder data at rest (Requirement 3.5.1) and in transit (Requirement 4.2.1) and salt stored password hashes (Requirement 8.3.2). Legal questions about any of these obligations belong with your counsel.

Quantum risk and cryptographic hygiene

Quantum computers change the risk picture unevenly. Running Shor's algorithm, a large enough quantum computer could break RSA, Diffie-Hellman, and ECC; today's hardware cannot, but projections put practical risk 10 to 30 years out, and the 'harvest now, decrypt later' threat means adversaries may already be storing encrypted data to open once capable hardware exists. NIST finalized its first post-quantum standards in August 2024, including FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), so design new systems for cryptographic agility, the ability to swap algorithms without a rebuild. Hash functions age better: Grover's algorithm only halves effective strength, leaving SHA-256 at about 128-bit security, which is still considered sound.

Day to day, the failures are operational, not mathematical. Keep encryption keys out of source code and away from the data they protect, store them in a key management system or hardware security module, rotate them on a schedule, and restrict access to least privilege. Keep an inventory of the algorithms you run, track NIST and CISA deprecation notices, and migrate off retired ones on a documented plan.