Encoding, hashing, and encryption can all change the way data looks, so it is easy to mix them up. But they are not the same thing. Each one solves a different problem, and choosing the wrong one can lead to weak security or simply make an application harder to work with.
Encoding changes data into another format so a system can store, process, or send it. Hashing turns data into a fixed-length value that can be used for things such as integrity checks and secure password storage when a proper password-hashing method is used. Encryption protects information from being read by people who should not have access to it, while still allowing an authorized person or system to recover the original data with the right key.
This guide explains encoding, hashing, and encryption in simple terms. It also looks at common algorithms, where they are used, common mistakes, and how to decide which approach fits a particular situation.
What is encoding?
Encoding means changing data from one format into another format by following a known set of rules. The goal is usually compatibility, not security. A system may need data in a particular format so it can be placed in a URL, sent through an API, stored in a text file, or handled by another application.
Base64 is a common example. It represents binary data, such as an image or file, using a limited set of text characters. For example, the word Hello becomes SGVsbG8= when encoded with Base64. The receiver can decode that value and get the original data back.
Because the rules are public, Base64 is not a secret. Anyone who has the encoded value can decode it. The RFC 4648 specification defines Base64 and other Base-N encodings.
That is the main difference between encoding and encryption. Encoding changes the representation of data. It does not try to hide the data from someone who can see it.
Common encoding formats
- Base64 represents binary data as text. It is commonly seen in email data, data URLs, and some APIs.
- Hexadecimal, often called hex, represents each byte using two hexadecimal characters such as 0-9 and A-F. Hash values are often displayed in this format.
- URL encoding represents characters that have a special meaning in a URL. For example, a space can be represented as
%20. - UTF-8 is a character encoding that represents Unicode text as bytes. It allows systems to work with text from many languages.
Here is a simple scenario. Imagine an application that needs to send an image through a service that expects text. The application can Base64-encode the image bytes, send the text, and let the receiving system decode it back into the original bytes.
Nothing was made secret in this process. The image was only represented in another format. If you need secrecy, use encryption. If you need to check whether data has changed, use a suitable integrity mechanism such as a cryptographic hash, MAC, or digital signature. Encoding has a different job.
What is hashing?
Hashing takes data of almost any size and produces a fixed-length value called a hash, hash value, or message digest. Give the same input to the same hash function and you get the same result. Change the input, even slightly, and a good cryptographic hash should produce a very different result.
For example, a software vendor may publish the SHA-256 hash of a download. After downloading the file, you can calculate the SHA-256 value of your copy and compare the two values. If they are different, the files do not have the same contents.
A cryptographic hash function is designed to make several attacks difficult. It should be difficult to work backward from the hash to the original input, and it should be difficult to find two different inputs that produce the same hash. A case where two different inputs produce the same hash is called a collision.
Hashing is not encryption. There is no secret key that you use to decrypt a normal cryptographic hash and recover the original data. However, weak or predictable inputs can sometimes be guessed. For example, an attacker who knows that a hash came from a short password can try likely passwords, hash each guess, and compare the results.
Hashing algorithms in practice
| Algorithm or family | Typical use | Guidance |
|---|---|---|
| MD5 | Legacy checksums and compatibility | Do not use it for security-sensitive applications that rely on collision resistance. |
| SHA-1 | Older systems and historical data | Do not choose it for new security designs that depend on collision resistance. |
| SHA-2 | Integrity checks, digital signatures, certificates, and HMAC-based designs | A widely used modern cryptographic hash family. |
| SHA-3 | General-purpose cryptographic hashing | A modern hash family with a different internal design from SHA-2. |
| BLAKE2 and BLAKE3 | Fast hashing and content identification | Modern hashing options for systems and applications that support them. |
MD5 and SHA-1 are still found in older software, archives, and compatibility systems. Seeing them in a legacy environment does not mean they are a good choice for a new security design. For new applications, the choice should be based on the security property you need, the protocol or standard you are following, and the libraries supported by your platform.
It is also important to separate general-purpose cryptographic hashing from password hashing. SHA-256, SHA-3, BLAKE2, and BLAKE3 are designed to be useful as general-purpose hash functions. Password-hashing algorithms have a different goal: they are deliberately made slower and more expensive to make password-guessing attacks harder.
Hashing passwords safely
Password storage is a special case. A common mistake is to take a password and simply calculate SHA-256(password). That is not a good password-storage design because SHA-256 is designed to be fast. If an attacker steals a database of fast password hashes, they can test a large number of password guesses relatively quickly.
For passwords, use a dedicated password-hashing or password-based key-derivation method. Common choices include Argon2id, scrypt, bcrypt, and PBKDF2. These methods are designed to make each password attempt more expensive. OWASP’s current password-storage guidance recommends Argon2id for new applications, with scrypt as an alternative and bcrypt mainly for systems that still need it for legacy reasons. PBKDF2 is also useful where its compatibility or validation requirements make it appropriate. See the OWASP Password Storage Cheat Sheet for current implementation guidance.
A unique random salt should be used for each password. A salt is an extra random value stored with the password hash. It means that two users with the same password will still have different stored hash values. It also makes precomputed password tables much less useful.
Here is a simple login scenario:
- A user creates an account and enters a password.
- The application creates a random salt.
- The password and salt are processed by the chosen password-hashing algorithm, such as Argon2id.
- The application stores the resulting password hash and the salt, not the original password.
- When the user logs in later, the application runs the submitted password through the same process and checks the result.
This does not make a stolen password database harmless. It means the attacker cannot simply read the original passwords from the database, and a properly configured password-hashing algorithm makes large-scale guessing more difficult and expensive.
Other uses of hashing
- File integrity: a known hash can be compared with a newly calculated hash to detect whether the file contents changed.
- Digital signatures: a hash is commonly used as part of the process of signing a message or document.
- Data identification: systems can use hashes as compact identifiers for files or pieces of content.
- Checksums: hashes and other checksum methods can help detect accidental changes. For security-sensitive integrity checks, a MAC or digital signature may be needed because an ordinary hash alone does not prove who created the data.
One important limitation is worth remembering: a hash does not prove that the data came from a particular person or organization. For example, if an attacker can replace both a file and the published hash, a simple hash comparison will not help. Digital signatures or another authenticated integrity mechanism can provide stronger assurance about the source.
What is encryption?
Encryption changes readable data, called plaintext, into ciphertext. The ciphertext should not be understandable to someone who does not have the required key or authorization. The purpose is confidentiality: keeping information from people who should not be able to read it.
Unlike hashing, encryption is designed to be reversible for an authorized party. If you encrypt a document with the right key, an authorized system can use the appropriate key to decrypt it later.
Encryption can protect information while it is stored and while it is moving between systems. The algorithm itself is only one part of the solution. The application also needs secure keys, safe configuration, proper authentication, and protection against unauthorized changes.
Symmetric encryption
Symmetric encryption uses a secret key to encrypt and decrypt data. The same secret key is used for both operations, although the exact details depend on the encryption mode and protocol.
AES, or Advanced Encryption Standard, is one of the most widely used symmetric encryption algorithms. ChaCha20 is another modern symmetric cipher used in software and network protocols.
For example, suppose an application needs to store a customer’s sensitive document. It can encrypt the document with a strong symmetric encryption method and store the ciphertext. When an authorized user needs the document, the application uses the appropriate key to decrypt it.
Authenticated encryption
Modern applications often need more than secrecy. They also need to know whether encrypted data was changed after it was protected. Authenticated encryption combines confidentiality with an integrity check.
AES-GCM and ChaCha20-Poly1305 are common authenticated-encryption choices. They produce encrypted data together with an authentication value that allows the receiving side to detect unauthorized changes. The nonce, sometimes called an initialization value, must be generated and used according to the algorithm’s rules. In particular, reusing a nonce with the same key in modes that require unique nonces can seriously weaken security.
Current TLS 1.3 deployments commonly use authenticated encryption suites such as AES-GCM and ChaCha20-Poly1305. Cloudflare’s current TLS documentation is one practical reference for seeing how these algorithms appear in real network configurations.
Asymmetric cryptography
Asymmetric cryptography uses a pair of related keys. The public key can normally be shared, while the private key must be protected.
Public-key cryptography can be used for different jobs depending on the algorithm and protocol. These include key agreement, authentication, encryption in some designs, and digital signatures.
RSA is a well-known public-key algorithm. Elliptic-curve cryptography, often shortened to ECC, includes methods such as ECDH for key agreement and ECDSA for digital signatures. These are not simply replacements for AES or ChaCha20. Symmetric encryption is generally used to protect the actual bulk data, while public-key techniques are often used to establish trust, authenticate a party, or help establish a shared secret.
How hybrid encryption works
Many real systems use symmetric and asymmetric cryptography together. This is called a hybrid approach.
A simple example looks like this:
- The system creates a temporary symmetric key.
- It uses that key to encrypt the actual data, which is efficient even for large files.
- The system uses public-key cryptography to protect or establish the symmetric key.
- The receiving side uses its private key or another agreed key-establishment method to obtain the symmetric key.
- The symmetric key is then used to process the protected data.
This approach works well because symmetric encryption is efficient for large amounts of data, while public-key cryptography solves some of the problems involved in establishing shared secrets between parties.
TLS, which is used by HTTPS, is a real-world example of a protocol that combines several cryptographic techniques. The exact steps depend on the TLS version and negotiated configuration, but the protocol provides authentication and key establishment and then uses symmetric authenticated encryption to protect application traffic.
Encryption at rest and in transit
Encryption at rest protects information while it is stored. Examples include an encrypted laptop drive, an encrypted database, a backup, or protected data in cloud storage.
Full-disk encryption can help if a laptop or storage device is lost or stolen. Application-level encryption can be useful when only certain fields or records need additional protection.
Encryption in transit protects information while it moves between systems. For example, HTTPS uses TLS to protect traffic between a browser and a website against network eavesdropping and unauthorized modification.
In both cases, key management is critical. Keys should be generated using suitable random sources, protected from unauthorized access, rotated or replaced when required, and retired safely. Larger organizations may use a dedicated key-management service or a hardware security module for important keys. OWASP provides additional guidance on cryptographic storage and key management.
Encoding vs hashing vs encryption
| Technique | Can you recover the original data? | Main purpose | Examples |
|---|---|---|---|
| Encoding | Yes, by decoding | Represent data in another format | Base64, UTF-8, URL encoding |
| Hashing | Not by decryption | Check data, identify content, or support password storage with a dedicated password-hashing method | SHA-256, SHA-3, Argon2id |
| Encryption | Yes, with the required key | Keep data confidential | AES-GCM, ChaCha20-Poly1305 |
Here is a simple way to see the difference. Start with the same text, such as CyberSecurityWaala.
- Encoding: the text can be converted to Base64 so another system can carry it as text. It can then be decoded.
- Hashing: the text can be passed through SHA-256 to create a fixed-length hash. There is no normal decrypt operation that turns that hash back into the original text.
- Encryption: the text can be encrypted with a key so that an authorized party can later decrypt it.
An online shopping application may use all three. UTF-8 can represent a customer’s name as bytes. URL encoding can safely represent special characters in a link. Password hashing can protect account passwords, while encryption can protect sensitive information that the application needs to read again later.
Choosing the right method
| If you need to… | Use | Reason |
|---|---|---|
| Represent data in another format | Encoding | It changes the representation without making the data secret. |
| Check whether a file or message changed | Cryptographic hashing | You can calculate the value again and compare it, although stronger authenticated integrity may be needed for security-sensitive cases. |
| Store user passwords | Password hashing | Dedicated methods make password-guessing attacks more expensive. |
| Keep information confidential and recover it later | Encryption | An authorized system can recover the protected information with the required key. |
| Protect network traffic | A secure protocol such as TLS | It combines cryptographic protection with authentication and integrity features. |
Common mistakes to avoid
- Treating Base64 as encryption. Base64 can be decoded without a secret key.
- Using SHA-256 alone for passwords. Use a dedicated password-hashing method such as Argon2id, scrypt, bcrypt, or PBKDF2 instead.
- Choosing MD5 or SHA-1 for new security-sensitive designs. Their known collision weaknesses make them unsuitable for new applications that need strong collision resistance.
- Encrypting passwords when they only need to be checked. In most applications, the original password should not need to be recovered, so password hashing is the better approach.
- Hardcoding encryption keys. A key placed directly in source code can leak through repositories, builds, logs, or reverse engineering.
- Ignoring nonce requirements. Some authenticated-encryption modes require a nonce to be unique for a given key. Reusing one incorrectly can seriously weaken the protection.
- Assuming a hash proves who created a file. A plain hash can show that two pieces of data differ, but it does not by itself prove who produced the data. A digital signature or authenticated mechanism may be needed.
The short version
Encoding is about changing the format of data so systems can work with it. Hashing creates a fixed-length value that can be used for integrity checks, content identification, and, with the right algorithm, password storage. Encryption is about confidentiality: protecting information so that an authorized party can recover it later.
The easiest way to avoid confusion is to ask what you actually need. If you only need a different data format, use encoding. If you need to check or identify data, consider hashing. If the data needs to stay secret and be recovered later, use encryption.
For security-sensitive work, use established algorithms, well-maintained libraries, and proven protocols instead of creating your own cryptographic method. The algorithm matters, but so do key management, configuration, authentication, and how the surrounding application uses it.
