Hashing vs Encryption vs Encoding

Encoding changes representation. Cryptographic hashing produces a digest. Encryption protects recoverable data using keys. Choose from the threat and recovery requirement, not from whether the output looks unreadable. Base64 is a representation format, not a confidentiality boundary.

Password verification is a distinct case: use a maintained password-hashing implementation with an appropriate work factor and salt. A fast digest or reversible encryption is not a substitute for that design.

TL;DR

Encode bytes when a transport or format needs another representation.
Use a digest to compare content against a trustworthy expected value; an untrusted digest cannot establish authenticity.
Use authenticated encryption when authorized software must recover confidential data and detect modification.
Store password verifiers with purpose-built password hashing, not plain SHA-256 or reversible encoding.
Treat key storage, nonce requirements, rotation, and failure handling as part of encryption.
Keep demonstrations separate from a production cryptographic format or reviewed security design.

Quick Example

Save this Node.js ES module as representations.mjs and run node representations.mjs. It uses fictional text and an ephemeral random key. It demonstrates representation, a digest, and authenticated encryption locally; it is not a password-storage implementation or durable encrypted-file format.

The key exists only in this process. Losing it makes this ciphertext unrecoverable. The example does not log the key or define how to store the nonce, tag, key identifier, or version. Those are necessary parts of a real format. Do not reuse a nonce under the same GCM key, and do not expose decrypted bytes before authentication succeeds. Node documents these APIs and authentication-tag handling in its crypto reference.

Core Concepts

Encoding represents bytes

Base64 maps binary data to a text representation. Anyone who knows the representation can decode it; no secret key is required. MDN's Base64 explanation describes the encoding and its use for binary data.

Encoding can appear around encrypted data because a JSON field or transport needs text. The outer encoding does not supply the encryption. Likewise, URL escaping or hexadecimal output can make bytes transportable without making them confidential.

Hashing supports comparisons, not recovery

A cryptographic digest summarizes input for purposes such as checking whether bytes match an expected value. There is no decryption key for SHA-256. However, a low-entropy input can still be guessed and its digest compared. “One-way” does not mean “impossible to guess.”

An attacker who can replace both a download and its displayed checksum can supply a matching digest. Authenticity needs a trustworthy reference or an appropriate keyed construction or signature. Do not silently convert a content-equality check into proof of who produced the content.

Encryption requires a key and a complete scheme

Authorized software can recover encrypted plaintext using the appropriate key and algorithm. Authenticated encryption also detects modification within its defined inputs and assumptions. OWASP's cryptographic storage guidance recommends authenticated modes and a deliberate key-management approach.

Choosing an algorithm is only one decision. The system also needs nonce generation, key access controls, format versioning, error behavior, recovery, and rotation. A correct cipher call cannot protect a key exposed to the same unauthorized reader as the ciphertext.

Choose from the required property

This is a decision map, not an implementation specification. Select maintained libraries and protocols for the actual use case rather than combining primitives into an improvised security format.

Passwords need a different cost model

A password verifier must make large-scale guessing expensive while keeping legitimate authentication practical. OWASP's password-storage guidance recommends modern password-hashing algorithms and unique salts, and explains why fast general-purpose hashes are unsuitable alone.

Use the library's supported encoded verifier format and verification routine. Preserve its algorithm and work-factor information so the application can upgrade verifiers as users authenticate. Tune the supported parameters against expected load and abuse conditions; copying a random iteration count from a tutorial does not settle capacity or security.

Do not “recover” forgotten passwords from stored encryption. Design a verified reset workflow. Also keep password hashing separate from session protection: a stolen valid session may bypass the password check entirely. The right password primitive does not compensate for missing authorization or unsafe account recovery.

Best Practices

Name the threat and recovery requirement

Ask who may read, modify, or replace the stored data and who must recover it. These answers distinguish encoding, integrity, authenticity, and confidentiality. Record what the scheme intentionally does not protect.

Define key ownership before storing ciphertext

Identify the authorized decryptor, key storage location, rotation procedure, and recovery test. Separate key-management permissions from ordinary data access where the design requires it. Test that unauthorized callers cannot invoke decryption through an application endpoint.

Treat verification failure as failure

Reject modified authenticated ciphertext and invalid signatures. Do not return partially processed plaintext or silently fall back to an older unprotected format. A migration path should be explicit and reviewable.

Common Mistakes

Calling Base64 encrypted

Bad: Put a credential in Base64 and treat the result as safe to disclose.

Correct: Treat encoded credentials as credentials. Use an appropriate secret store and transport protection; encode only when the format requires it.

Using a fast hash as a password verifier

Bad: Store SHA256(password) and assume the digest prevents guessing.

Correct: Use a supported password-hashing library with unique salts and reviewed parameters. Keep reset and session controls in scope.

Losing the encryption context

Bad: Save ciphertext while discarding the algorithm version, nonce, tag, or key identifier.

Correct: Define a reviewed format and lifecycle. Keep keys protected and test recovery with the exact stored representation.

FAQ

Can I decrypt a hash?

No decryption operation exists for a digest such as SHA-256. Guessing an input and comparing its digest is a different attack, which is why passwords require expensive verifiers and other account protections.

Is an encrypted value also encoded?

It may be encoded for transport or storage. Encoding describes representation; encryption describes protection. The two can coexist without becoming the same operation.

Is a checksum enough to trust a download?

Only if the expected value comes through a trustworthy path and the chosen check fits the threat. Replacing both the file and an untrusted checksum defeats a simple comparison.

Should applications implement their own cryptographic scheme?

Prefer established protocols, maintained libraries, and a reviewed design. The demonstration above teaches properties and failure handling; it does not replace key management or a security review.