DevKit Tools

Hashing vs Encryption vs Encoding: What Is the Difference?

3 min read4 October 2026By Muhammad Abdullah

Hashing, encryption and encoding all turn readable data into something that looks like gibberish, so they are easy to confuse. But they do completely different jobs, and using one where you needed another is behind a long list of real security failures. The difference comes down to one question: who can turn it back?

Try it as you readHash GeneratorCompute SHA-256, SHA-384, SHA-512 and legacy SHA-1 digests with the Web Crypto API. Runs entirely in your browser.

Encoding: a change of format, not a secret

Encoding rewrites data in a different form so it can travel safely through a system that expects a certain kind of text. Base64 turns any bytes into letters, digits and a few symbols so they can sit inside JSON, an email or a URL. URL encoding turns a space into %20.

Anyone can reverse encoding. There is no key. It is exactly as secret as the original data.

text
hello        ->  aGVsbG8=     (Base64)
aGVsbG8=     ->  hello        (anyone can decode it)

Encryption: secret, but reversible with a key

Encryption scrambles data so that only someone with the right key can turn it back. HTTPS encrypts the traffic between your browser and a website. A password manager encrypts your vault with a key derived from your master password.

Use encryption when you need the original data back later, but only for the right people. The security rests entirely on the key: who has it, and where it is kept.

Hashing: a one-way fingerprint

A hash function turns any input into a fixed-length fingerprint. The same input always gives the same hash, the smallest change gives a completely different one, and there is no way to run it backwards to get the input.

text
SHA-256("hello")  2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
SHA-256("Hello")  185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969

Hashes are used to check that a file downloaded correctly, to spot whether two pieces of data are identical without comparing them byte by byte, and to store passwords so that the site itself never knows them.

MD5, SHA-1 and SHA-256

  • MD5 and SHA-1 are broken for security: people can deliberately create two different inputs with the same hash. They are still fine as a quick checksum against accidental corruption.
  • SHA-256 is the safe general-purpose choice today, for file checks, signatures and identifiers.
  • None of them should be used on their own to store passwords, for the reason below.

How passwords should be stored

SHA-256 is designed to be fast, and fast is exactly what you do not want for passwords. A single graphics card can try billions of SHA-256 guesses a second, so if a database of plain SHA-256 password hashes leaks, the common passwords fall almost at once.

Password hashing functions such as Argon2, bcrypt and scrypt are deliberately slow and use a lot of memory, which makes each guess expensive. They also add a salt: a random value stored with each hash, so two people with the same password get different hashes and an attacker cannot crack everyone at once with one precomputed table.

Common questions

Can a hash be decrypted?

No. Hashing is one-way. Attackers "crack" hashes by guessing inputs and hashing each guess until one matches, which is why slow password hashes matter.

Is Base64 encryption?

No. Base64 is an encoding that anyone can reverse without a key. It provides no secrecy at all.

Is MD5 safe to use?

Not for security, because collisions can be created on purpose. It is still acceptable as a checksum for detecting accidental corruption.

Tools from this guide

More guides