I’ve found it a lil tough to translate my mental model about XYZ topic into words for juniors. I can explain it to them, but I’m making up stuff on the fly when I do that. So I’m writing this one down.
Encryption, compression, encoding, hashing, checksums, error correction. These get mixed up constantly, so here is how I explain them: tools in a toolbox, each built for a different job. Say you’re shipping a package.
Encryption = a locked safe
Keeps secrets safe from prying eyes. It scrambles data into gibberish unless you have the key (e.g., AES, RSA). Like writing a letter in invisible ink: only someone with the right UV light (the key) can read it.
Use it when you need confidentiality - passwords, credit card numbers.
Two flavors:
- Symmetric: one key locks and unlocks. A diary lock.
- Asymmetric: a public key locks, a private key unlocks. A mailbox - anyone can drop mail in, only you can open it.
Compression = a vacuum-sealed bag
Saves space by reducing file size. It works by removing redundancy or approximating the data.
- Lossless reconstructs the original perfectly. Folding clothes.
- Lossy discards the less important details. Squashing a stuffed animal - it’s smaller, but some fluffy details are gone.
A ZIP file is a suitcase. A JPEG is a crumpled poster.
Use it for storing or transmitting large files - videos, logs.
Encoding = translating a book
Represents data in a different format. The goal is compatibility, not security or space. It converts data into a standard “language” other systems understand. Base64 turns binary data into text (e.g., email attachments).
Like writing a recipe in Morse code: same recipe, just dots and dashes.
Use it when systems need data in a specific format - URLs, APIs.
And because people get this wrong all the time: encoding is not encryption. Morse code isn’t a secret.
Hashing = a fingerprint
Uniquely identifies data. It turns data into a fixed-size string (the hash) that is unique to the input - SHA-256, MD5.
Think of the tamper-evident seal on a medicine bottle. If the seal breaks (the hash changes), you know the data was altered.
Use it for verifying integrity - passwords, file downloads.
Checksums and error correction = a spaceship checklist
Detects or fixes errors in data.
- A checksum adds a simple “total” to detect corruption (e.g., CRC32).
- Error-correcting codes add redundancy so you can fix errors (e.g., RAID, QR codes).
A pilot’s pre-flight checklist (checksum) vs packing spare parts (error correction).
Use it for data transmission and storage in unreliable environments - networking, DVDs.
Key differences
| Encryption | Compression | Encoding | Hashing | |
|---|---|---|---|---|
| Goal | Confidentiality | Save space | Compatibility | Integrity/ID |
| Reversible? | Yes (with key) | Lossless: Yes Lossy: No | Always | No (one-way) |
| Changes data? | Yes (scrambled) | Yes (smaller) | Yes (format) | No (creates a fingerprint) |
Which tool when
Ask what the problem is first:
- “Need to hide data?” → encryption.
- “Need to save space or bandwidth?” → compression.
- “Need to make sure data isn’t corrupted?” → hashing or a checksum.
- “Need data in a specific format?” → encoding.
And the usual mix-ups:
- Encoding ≠ encryption. Base64 isn’t secure.
- Hashing ≠ encryption. You can’t “decrypt” a hash.
- Compression ≠ smaller forever. Lossy compression discards data.
Each tool solves one problem: lock it (encryption), shrink it (compression), translate it (encoding), fingerprint it (hashing), protect it (checksums/error correction). Start with the goal - security, space, integrity - and pick the tool that matches.