The Three Pillars of Digital Trust: Encoding, Hashing, and Encryption

By Pushkar Kumar, Senior Technical Consultant — GeekyAnts

---

In today's digital economy, trust is the real currency. Every application we build — whether it's a consumer app, an enterprise workflow, or an internet-scale platform — depends on how we handle data. Yet even among seasoned engineers, there's persistent confusion between encoding, hashing, and encryption.

As someone who has led architecture reviews across large-scale systems, I've seen this confusion surface everywhere: in design documents, security audits, and even senior-level interviews. A simple misstatement like "we encrypt passwords using bcrypt" isn't just a slip of terminology — it signals a gap that can cascade into design flaws, compliance failures, and security vulnerabilities.

This article is not just a refresher on definitions. It's a field guide for technical leaders, engineers, and architects who want to make deliberate, correct choices about data handling. By the end, you'll have absolute clarity on when to encode, when to hash, and when to encrypt — and why getting this right is foundational for building resilient, trustworthy systems at scale.

---

What is Encoding?

Encoding transforms data into a format that's safe to transmit or store — especially across systems that expect text, not raw binary.

It's not about hiding data — it's about making sure it doesn't break things when passed through a browser, stored in a file, or sent over a network.

Why Do We Encode?

Imagine you're sending a binary file (like an image or a PDF) in an email. Email protocols expect text, not raw binary bytes. You need to transform that file into a format that plays nicely with the medium. That's what encoding does.

Key Traits

• Reversible — Anyone can decode it; no secrets involved

• Not secure — Base64 is not protection; it's just translation

• Used for compatibility — Across systems, platforms, and protocols

Purpose: Format compatibility, not confidentiality

Common Types of Encoding

Type	Use Case
Base64	Encoding binary data for text-based transport (email, APIs)
URL Encoding	Making query strings browser-safe (e.g., space → %20)
HTML Encoding	Displaying reserved characters safely (e.g., < → &lt;)
Unicode (UTF-8)	Representing text across different languages and systems

Code Example

// Encoding
const encoded = Buffer.from("Hello, World!").toString("base64");
console.log(encoded); // SGVsbG8sIFdvcmxkIQ==

// Decoding
const decoded = Buffer.from(encoded, "base64").toString("utf-8");
console.log(decoded); // Hello, World!

Base64 inflates data by ~33%, but makes it safe to transmit over text-based channels.

(Re-upload the encoding/decoding flowchart image from the original article here)

Encoding is a round trip — you're guaranteed to get back what you put in.

Real-World Use Cases

1. Emails — Attachments are encoded in Base64 so they don't break email formatting

2. URLs — Query strings need URL encoding so special characters don't confuse browsers

3. HTML Pages — Displaying <script> without it executing? Use <script>

4. APIs — Some APIs require encoded payloads to ensure safe transmission

Encoding ≠ Security

Many developers confuse Base64 with encryption. That's dangerous.

Here's what anyone can do:

echo "SGVsbG8sIFdvcmxkIQ==" | base64 --decode
# Hello, World!

No key, no secret — just a simple tool. That's why encoding should never be used to store or protect sensitive information.

Analogy: The Universal Translator

Imagine sending a handwritten note to someone in another country.

• Encoding is like using Google Translate so their email system understands your text.

• It's not private — the mailman, post office, or anyone in-between can read it.

• But it ensures the message doesn't get corrupted in transit.

So, when you Base64-encode a token or a file, you're just making sure it survives the journey — not locking it away.

Common Mistake to Avoid

"We store the API token in Base64 so it's safe."

✅ It's compatible. ❌ It's not secure.

Anyone can decode Base64 in milliseconds. Always pair encoding with encryption if you need protection.

---

What is Hashing?

Hashing is the process of turning any data — a password, a file, or a string — into a fixed-length, irreversible fingerprint.

It's how we verify something hasn't been tampered with, without needing to look at the original.

Why Do We Hash?

Let's say you download a 2 GB file. How do you check it hasn't been corrupted or altered in transit? You compare its hash with the official hash published by the source. If they match, you're good.

Key Traits

• One-way — You can't reverse it to get the original data

• Deterministic — Same input → same hash, always

• Fixed-size output — No matter the input size

• Collision-resistant — Hard to find two different inputs with the same hash

Purpose: Verify identity or detect change

Common Hash Algorithms

Algorithm	Output Length	Use Case
MD5	128 bits	Legacy checksums (not secure)
SHA-1	160 bits	Git commits (deprecated)
SHA-256	256 bits	File integrity, blockchain
bcrypt	Variable	Password hashing (with salt)
scrypt	Variable	Password hashing (slower, safer)
argon2	Variable	Modern password hashing standard

(Re-upload the hashing flowchart image from the original article here)

You can compare hashes, but you can't go backward.

Hashing Passwords (with Salt)

Hashing alone isn't enough for passwords. You also need salt — a unique random value added to the input to prevent dictionary and rainbow table attacks.

const bcrypt = require("bcrypt");

const password = "mySecurePassword";
const saltRounds = 12;

// Hashing
const hash = await bcrypt.hash(password, saltRounds);

// Verification
const isMatch = await bcrypt.compare(password, hash);
console.log(isMatch); // true

Salting ensures that even if two users have the same password, their hashes will be completely different — defeating precomputed attacks.

Real-World Use Cases

• Password storage — Use bcrypt, scrypt, or argon2

• Git commits — Each commit has a SHA-1 hash

• File checksums — Validate downloaded files

• Cache keys — Quickly compare request payloads

Analogy: The Fingerprint Scanner

Hashing is like scanning your fingerprint:

• It's unique to you

• It doesn't store your actual finger

• If someone tampers with it, it won't match again

---

What is Encryption?

Encryption is the process of locking data so only the right person can unlock it. It's the cornerstone of confidentiality in digital systems.

Unlike encoding (which changes format) or hashing (which verifies identity), encryption transforms readable data into unreadable ciphertext — but in a way that can be reversed if you have the key.

Why Do We Encrypt?

If you're handling personal data, sensitive files, or confidential messages, you don't want anyone snooping on them during transit or storage. Encryption ensures:

• Only the right person can read it

• Even if intercepted, it's meaningless without the key

• You stay compliant with regulations (GDPR, HIPAA, PCI-DSS)

Key Properties of Encryption

• Reversible — Data can be decrypted using the correct key

• Key-based — Requires either a single key (symmetric) or key pair (asymmetric)

• Confidential — Protects the contents of data from unauthorized access

---

Types of Encryption

Symmetric Encryption

• One key used for both encryption and decryption

• Fast and efficient — best for large data

• Examples: AES, DES, ChaCha20

• Use Cases: Disk encryption (BitLocker, FileVault)

const crypto = require("crypto");

const key = crypto.randomBytes(32); // 256-bit key
const iv = crypto.randomBytes(16);  // Initialization Vector

const cipher = crypto.createCipheriv("aes-256-cbc", key, iv);
let encrypted = cipher.update("Sensitive Data", "utf8", "hex");
encrypted += cipher.final("hex");

console.log(encrypted);

Asymmetric Encryption

• Uses a key pair: public key to encrypt, private key to decrypt

• Enables secure communication over public networks

• Examples: RSA, ECC

• Use Cases: TLS handshakes (HTTPS)

Hybrid Encryption

• Combines both: asymmetric to exchange a session key, symmetric to encrypt the actual data

• Gets the best of both: security + speed

• Examples: TLS (HTTPS), Signal Protocol

• Use Cases: Secure web traffic

---

Protecting Your Keys

Encryption is only as strong as key management. Here's how to do it right:

Key Management Best Practices

1. Never hardcode keys in your source code

2. Use a Key Management Service (KMS) such as:

   • AWS KMS

   • HashiCorp Vault

   • Google Cloud KMS

3. Rotate keys regularly (e.g., every 90 days)

4. Use environment variables as a baseline

5. Encrypt your config files

6. Never log secrets — even in dev!

---

Authenticated Encryption (AEAD)

Standard encryption doesn't always protect against tampering. Use AEAD (Authenticated Encryption with Associated Data) to defend against both snooping and forgery.

Recommended algorithms:

• AES-GCM

• ChaCha20-Poly1305

These algorithms ensure the data is unreadable and any modifications are detected and rejected.

---

Common Encryption Mistakes

• Using ECB mode with AES — This mode always encrypts the same input the same way, so patterns in your data become visible. Always use CBC, GCM, or CTR mode instead.

• Reusing IVs (Initialization Vectors) — An IV is a random "starting point" for encryption. Reusing it lets attackers infer patterns. Always generate a fresh IV for every encryption operation.

• Writing your own encryption code — Cryptography is notoriously tricky. Even small mistakes can break your entire system. Always use trusted, battle-tested libraries.

• Storing encryption keys in plain files or GitHub — If someone finds the key, your encryption is useless. Use AWS KMS, HashiCorp Vault, or equivalent secrets managers.

Analogy: Sending a Locked Box

• Symmetric — You and the recipient share the same key to lock and unlock

• Asymmetric — You send the recipient a locked box (using their public key), and only they can open it (with their private key)

• Hybrid — You mail them a box with a padlock key inside; only they can open the box (asymmetric), then both use that key to send more data (symmetric)

---

Common Developer Mistakes (All Three Combined)

Mistake	Why It's Wrong
"We encrypt passwords using SHA-256"	SHA-256 is hashing, not encryption — and it's not suitable for passwords without salting
"We store the API token in Base64 so it's secure"	Base64 is encoding — anyone can decode it instantly
"AES is a one-way encryption"	AES is reversible; one-way describes hashing
Confusing JWT signature with encryption	JWT's default signature (HS256) verifies integrity — it does not hide the payload

---

When to Use Encoding, Hashing, or Encryption

🔄 Use Encoding

When: You need to safely transmit data (like in a URL, email, or HTTP header)
Why: Converts data into a compatible format — not secret, just safe to transport
Example: Base64 for image data, %20 in URLs

🧮 Use Hashing

When: You want to create a fingerprint of data or check if something has changed
Why: A hash is a one-way, fixed-length output that changes drastically with even 1 bit of difference
Example: SHA-256 for file verification, bcrypt for passwords

🔐 Use Encryption

When: You need to protect data from being read by anyone else
Why: Encryption scrambles data so only someone with the correct key can read it
Example: HTTPS, AES-encrypted files, secure messaging apps

🛡️ Use Hashing with Salt

When: You're storing user passwords
Why: Hashing ensures you can verify passwords without ever storing the original. Salt makes each hash unique
Example: bcrypt, argon2, scrypt

📬 Use Encryption

When: You're sending secrets over public networks
Why: Without encryption, anyone in the middle (e.g., on public Wi-Fi) could read your data
Example: TLS/SSL for websites, VPNs for secure tunneling

---

Quick Rule of Thumb

• Encoding → make data compatible

• Hashing → verify or fingerprint

• Encryption → protect and hide data

---

Final Thoughts

Encoding, hashing, and encryption aren't just technical details — they are the foundations of digital trust. Misusing them can mean the difference between a resilient system and one that silently carries risk.

As engineers and architects, our responsibility goes beyond "making things work." We are building platforms that handle personal data, financial transactions, and critical infrastructure. Getting these fundamentals right is non-negotiable.

At GeekyAnts, we invest deeply in engineering practices that balance performance, security, and clarity. Our teams are trained to ask the right question at the right time:

"Do I need format compatibility, verification, or confidentiality?"

That simple pause ensures the correct choice between encoding, hashing, or encryption — and prevents costly mistakes down the road.

• Encoding makes systems talk.

• Hashing verifies integrity.

• Encryption protects secrets.

Get those right, and you're not just solving today's problem — you're designing for the future of secure, trustworthy digital systems.

---

Originally published on GeekyAnts Blog.

GeekyAnts is a technology studio helping enterprises build secure, scalable digital products. Need architecture guidance or a security-first engineering partner? Talk to our team.