Encoding vs encryption vs hashing: what's the difference?

Encoding, encryption and hashing all transform data, but they do different jobs. Encoding changes the format so systems can carry the data, and anyone can reverse it. Encryption hides data so that only someone with the key can read it. Hashing turns data into a fixed-length fingerprint that can't be reversed at all, which makes it right for checking integrity and storing passwords.

Three jobs: format, secrecy, integrity

The quickest way to tell them apart is to ask which problem each one solves and what it needs:

• Encoding solves a format problem. Binary data has to pass through a system that only accepts text, or a URL can't contain spaces. No secret is involved.
  
  
• Encryption solves a secrecy problem. Someone may see the data in transit or at rest, and they must not be able to read it. It needs a key.
  
  
• Hashing solves an integrity problem. You need to know whether data has changed, or to check a password without storing it. It needs no key and can't be undone.
  
  

Most confusion, and a surprising number of security bugs, come from using one of them to do another's job.

Encoding

Encoding maps data into another representation using a public, fixed rule. You meet it everywhere:

• Base64 turns bytes into 64 printable characters for email attachments, JSON APIs and tokens. The text UPSC becomes VVBTQw==.
  
  
• URL (percent) encoding makes text safe inside a web address. A search for "₹999 UPSC batch" becomes %E2%82%B9999%20UPSC%20batch, because the rupee sign is three bytes in UTF-8 and a space becomes %20.
  
  
• UTF-8 is itself an encoding: it maps characters such as ₹ to bytes, here E2 82 B9.
  
  
• Hex writes each byte as two digits, which is how hashes are usually displayed.
  
  

Anyone who recognises the scheme can reverse it instantly, and there is no key to protect. That is why "Base64 encryption" is a contradiction in terms, as our explainer on why Base64 isn't encryption shows.

Encryption

Encryption combines an algorithm with a secret key to produce ciphertext that looks random to anyone without the key; with the key, it reverses exactly. Modern ciphers such as AES-GCM and ChaCha20-Poly1305 also attach a tag that detects tampering. For the fundamentals, see what encryption is.

Two properties are easy to miss:

• Good encryption is randomised. Encrypting the same file twice with the same key gives two different ciphertexts, because each encryption uses a fresh nonce. Encoding and hashing always give the same output for the same input.
  
  
• The output is about as long as the input. A 2 GB lecture stays about 2 GB when encrypted, plus a few bytes of nonce and tag per message.
  
  

Hashing

A cryptographic hash function such as SHA-256 turns any input, from one character to a 2 GB video, into a fixed 256-bit value, usually written as 64 hexadecimal characters. The same input always gives the same hash, a one-character change gives a completely different one, and there is no key and no way back. You check a hash by recomputing it and comparing, never by reversing it.

Hashing is used to verify downloads and evidence, to deduplicate files, inside digital signatures and, in deliberately slow forms, to store passwords. Our guide to what hashing is covers the properties that make a hash secure.

Where salting and obfuscation fit

Salting belongs to hashing

A salt is a random value, unique to each password, that is combined with the password before hashing and stored next to the hash. It isn't secret. It makes two users with the same password end up with different hashes and makes precomputed tables useless, so an attacker must crack each account separately. A pepper is different: a secret key applied on top, kept outside the database, for example in a secrets vault (OWASP). Neither is enough on its own; the hash must also be slow, which is why password hashing uses Argon2id, scrypt or bcrypt rather than plain SHA-256.

Obfuscation sits next to encoding

Obfuscation makes code or data hard for a person to follow without making it mathematically secret. Android's R8 build tool, for example, shortens class and method names, so com.example.MyActivity can become a.b.a, and Google presents this mainly as a way to shrink the app (Android Developers). Obfuscation raises the effort for anyone reverse-engineering an app, which is useful as one layer, but a key hidden by obfuscation is still inside the app for anyone patient enough to find it.

Keyed hashes sit between hashing and encryption

Mix a secret key into a hash in the right way and you get an HMAC, which proves that a message came from someone holding the key and wasn't altered. Payment gateways use it to sign webhooks. It still hides nothing: the message stays readable. Our guide to how HMAC works explains the details.

Side-by-side comparison

Which one do you need?

Here is how common tasks on an education platform map to the right tool:

Common mix-ups in real code

1. "Encrypting" secrets with Base64. MITRE lists this weakness as CWE-261, weak encoding for password: anyone who can read the config file can decode it (CWE-261).
   
   
2. Encrypting passwords instead of hashing them. If a system can decrypt passwords, so can anyone who steals the key, and so can curious staff. A site that can email you your old password is storing it reversibly.
   
   
3. Hashing passwords with a fast hash. Unsalted MD5 or SHA-256 can be guessed at enormous speed once a database leaks.
   
   
4. Hashing short values to "anonymise" them. A 10-digit mobile number has at most ten billion possible values, so an attacker can hash every one and match. A plain hash of a phone number is still, in effect, the phone number.
   
   
5. Building a signature as SHA-256(secret + message). SHA-256's internal structure allows a length-extension attack on this construction, letting an attacker append data and compute a valid value without the secret. HMAC exists to prevent exactly this.
   
   
6. Encrypting without authentication. Unauthenticated modes let an attacker alter ciphertext in ways that survive decryption. Use an authenticated mode such as AES-GCM, as our comparison of AES-GCM and AES-CBC shows.
   
   
7. Using a hash of an ID as a secret link. SHA-256 of a student ID looks random, but anyone who knows the ID can compute it. Unguessable links need random tokens or signatures.
   
   

Key takeaways

• Encoding changes format, needs no secret and is reversible by anyone. It is never security.
  
  
• Encryption needs a key, is reversible only with that key, and should be randomised and authenticated.
  
  
• Hashing is one-way and keyless; it checks data rather than hiding it.
  
  
• Salts, peppers and slow algorithms turn hashing into safe password storage; HMAC turns it into message authentication.
  
  
• Obfuscation only slows people down. Keys hidden by obfuscation or Base64 are still exposed.
  
  

Frequently asked questions

Is encryption the same as hashing?

No. Encryption is reversible by design: with the right key you get the original data back. Hashing is one-way: it produces a fixed-length fingerprint, and no key turns it back into the input. Use encryption when someone authorised must read the data later, and hashing when you only need to check it, such as verifying a file or a password at login. Passwords should be hashed, not encrypted.

Is encryption the same as encoding?

No. Encoding, such as Base64 or URL encoding, follows a public rule and needs no secret, so anyone can reverse it. It exists to make data fit a format, not to hide it. Encryption needs a key, and without that key the output is unreadable. Data is often both: encrypted first for secrecy, then Base64-encoded so the ciphertext can travel inside JSON or a URL.

Is encryption reversible?

Yes, for anyone holding the correct key; that is its purpose. Symmetric encryption such as AES reverses with the same key that encrypted the data, and asymmetric encryption such as RSA reverses with the private key matching the public key that was used. Without the key, a modern algorithm used correctly can't be reversed in practice, which is why a lost key usually means lost data.

Does encryption use hashing?

Often, although the two do different jobs. TLS 1.3, which secures HTTPS, derives its encryption keys with HKDF, a function built on HMAC and SHA-256 or SHA-384 (RFC 8446). Digital signatures hash the message before signing it, and password-based encryption stretches your password with a slow hash to produce the key. The cipher does the encrypting; hash functions support it.