Encryption vs Hashing vs Encoding: Key Differences

The difference at a glance

Encryption protects secrecy, hashing produces a digest for comparison, and encoding changes how data is represented. Encryption is designed to be reversed with the correct key; encoding can be reversed without a secret; a cryptographic hash has no decryption operation.

These operations can appear in the same system. A string that looks scrambled tells you little about its protection. Ask what operation produced it, what threat it addresses, and who can recover or test the underlying value.

Encoding: readable by anyone who knows the format

Base64 represents bytes using a limited set of printable characters. For a harmless example, the UTF-8 text hello becomes aGVsbG8=. Decoding returns hello; no password or secret is involved. RFC 4648 specifies Base64 and related encodings.

That is useful when binary data must travel through a text field. It provides compatibility, not confidentiality. An API credential remains a credential when represented in Base64. Someone who obtains it may decode and use it just as they could use the original value.

Do not paste real tokens, passwords, or private documents into an online decoder to investigate them. Use synthetic values for learning and approved local tools for sensitive material. If an encoded credential has been exposed, decoding it is not a remediation step: follow the relevant secrets-management process to revoke or replace it.

Encryption: recoverable data, protected by keys

Suppose a payroll team needs to keep a report and read it next month. Hashing would not preserve a recoverable copy; encoding would leave it readable to anyone. Encryption fits the requirement because authorized software can decrypt the ciphertext back into plaintext.

Symmetric encryption uses the same secret key for encryption and decryption. Asymmetric encryption uses a related public/private key pair: a sender can encrypt for a recipient using the public key, while the recipient keeps the private decryption key secret. Real systems often combine asymmetric mechanisms with symmetric encryption rather than encrypting an entire file directly with a public-key algorithm.

Implementation matters. OWASP’s cryptographic storage guidance recommends established cryptography and authenticated encryption, which also detects unauthorized ciphertext changes. Use maintained libraries and supported product features rather than designing an algorithm yourself.

Ask where protection ends. A stolen powered-off laptop and malware reading files from an unlocked session are different threats. Disk encryption can address the first without preventing the second; NCSC’s data-security guidance explains this limit. The everyday device-security guide connects encryption with updates, access controls, and loss preparation.

Hashing: compare bytes without recovering them

A cryptographic hash such as SHA-256 maps input bytes to a fixed-length digest. The same bytes produce the same digest. SHA-256 outputs 256 bits, commonly displayed as 64 hexadecimal characters. A digest is not a compressed copy you can unpack.

NIST’s definition of a cryptographic hash describes resistance to finding an input for a given digest and to finding different inputs with the same digest. Collisions are mathematically possible; secure algorithms make finding useful ones computationally impractical. Calling every digest “unique” overstates the guarantee.

For a software download, compute its SHA-256 digest and compare it with the publisher’s expected value. The reference must come from a trustworthy source. If an attacker replaces both the file and the digest beside it, the comparison can pass. Even a correctly verified digest does not tell you whether the publisher’s original file contains harmful code.

Digital signatures add a different assurance: verification links the signed data to a signing key, subject to trusting that key and its owner. They do not make software automatically safe either. See build provenance and artifact signing for the checks around that trust decision.

Why password hashing needs special treatment

A hash can resist reversal while still allowing guesses. An attacker can take a likely password, apply the same hashing process, and compare the result with a stolen record. A match identifies a working candidate without decrypting anything.

That is why a fast file-hashing algorithm is a poor choice for storing login passwords. OWASP’s password-storage guidance recommends purpose-built password hashing such as Argon2id, with an appropriate cost and a unique salt per password. A salt is a non-secret value stored with the record; it prevents reuse of the same precomputed work across many passwords. It does not make a weak password unguessable.

There are two different requirements here. A website normally needs to verify a login password, so it stores a password-hashing record. A password manager needs to retrieve saved credentials, so its vault needs recoverable protection. For the account-level decisions, use the guide to password managers and credential reuse.

Choose by what you need to do next

Consider sending a confidential report through a text-only interface. First encrypt the report using a supported mechanism. Then encode the encrypted bytes as Base64 if the interface requires it. The recipient decodes the wrapper and decrypts the result. Encoding did not add secrecy, and decoding did not remove the encryption.

Use these questions when reviewing a design or a product claim:

• Must an authorized person recover the original? Use encryption with controlled decryption access and a workable key-recovery plan.
• Must you compare a file with a known version? A cryptographic digest can help, provided the expected value is trustworthy.
• Must a service verify a password? Use a purpose-built password-hashing implementation.
• Must bytes fit a text field? Encoding may solve the format problem; assess confidentiality separately.
• Must you establish who signed data? Use signature verification with an explicit trust decision about the signing key.

Before accepting “encrypted” as an answer, ask who holds the keys and whether the application can read the data during normal use. Before accepting “hashed,” ask whether someone can guess the inputs or replace the reference. These questions reveal the actual protection more reliably than the appearance of the stored value.