IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Encoding, encryption and hashing — three different things
Three words sound alike: encoding, encryption and hashing. They mean very different things. Mixing them up causes real security failures. Your goal: say which one to use to hide data, and which one to use to compare data.
- Encoding repacks data. Anyone can undo it. It hides nothing.
- Encryption hides data. Only the key can unlock it.
- Hashing makes a one-way fingerprint. You cannot go back.
- Base64 is encoding, never encryption.
Encoding: repacking, not hiding
Encoding changes data into another shape so it can travel safely. That is all. The best-known kind is Base64. It turns any data into plain letters and numbers. Anyone can undo it at once. There is no key and no secret. It gives no secrecy at all.
writing a Tamil book in English letters. The words look different, but anyone who knows the code can read it. You did not lock the book. Base64 is a different alphabet, not a lock.
Encryption: a real lock with a key
Encryption scrambles data with a key. Only someone with the right key can unscramble it. Without the key, the result is useless nonsense. This protects your data on the internet. The padlock in your browser shows that encryption is working.
Hashing: a one-way fingerprint
Hashing puts data through a one-way blender. Out comes a short fingerprint of fixed size. Two rules matter.
- The same input always gives the same fingerprint.
- Change one letter and you get a totally different one.
And you cannot go backwards. No key turns a fingerprint back into the original.
A hash does two jobs. Sites use it to store passwords (see lesson 8). Publishers use it to prove a download was not changed. If your copy gives the same fingerprint as the published one, it is the same file.
| Can you reverse it? | Needs a key? | What it is for | |
|---|---|---|---|
| Encoding (Base64) | Yes, anyone can | No | Making data travel safely. Example: the readable parts of a JWT. |
| Encryption | Yes, but only with the key | Yes | Keeping data secret while it travels or sits in storage. Example: the padlock on websites. |
| Hashing | No, never | No | A fingerprint to compare without keeping the original. Example: password storage. |
Zara, on the security team, checks a partner's setup. She finds them emailing "encrypted" passwords. It is only Base64. Anyone who reads one email can decode the password in a second, with no key. The team felt safe because the text looked scrambled. "We encoded it, so it is secure" is the mistake to avoid.
Base64 is not encryption. It hides nothing. The middle of a JWT is encoded, not encrypted. Anyone who holds the token can read it with no key. If something must stay secret, encrypt it or hash it. Never only encode it.
🧪 Interactive lab — enable JavaScript to play with this one.
See "encoded, not encrypted" with your own eyes. Paste any JWT into ID Token Check. Its Base64 middle part opens at once, with no key or password.