Base64, Hashing and Encryption: What Each One Actually Does

A developer opens a configuration file and finds dXNlcjpwYXNz next to a field called password. It looks scrambled, so it must be protected, right? It decodes in one step to user:pass. Base64, hashing, encryption, URL encoding and token formats all change text into other text, which is why they get confused, and confusing them causes real security mistakes. This guide separates them by the question each one answers, then shows how to work with each in the browser.

Encoding: Base64 changes the shape, not the secrecy

Base64 turns any bytes into 64 safe, printable characters (A to Z, a to z, 0 to 9, plus and slash) so that binary data can travel through channels built for text, such as JSON fields, email bodies and data URLs. Every 3 bytes become 4 characters, so the result is about one third larger. The text Hello becomes SGVsbG8=, and the equals sign is padding, added because the input does not fill a whole 3-byte block.

Nothing about this is secret. The value in that config file is how HTTP Basic authentication sends a username and password, and anyone can reverse it. Treat a Base64 string as plain data in a different costume.

Variants you will meet:

• URL-safe Base64 swaps plus and slash for hyphen and underscore and usually drops the padding. JWTs use it, and a decode that fails on those characters usually means the wrong variant.
• MIME Base64 wraps lines at 76 characters for email.
• Base32 uses only A to Z and 2 to 7, ignores case and is what authenticator apps use for secret keys. It grows data by about 60 percent.

The Base64 Encoder Decoder handles UTF-8 correctly (accents, non-Latin scripts and emoji), offers URL-safe output and 76-character wrapping, accepts unpadded or line-wrapped input, strips a data: prefix, encodes files up to 20 MB and offers decoded binary as a download instead of showing garbage. For authenticator keys use the Base32 Encoder, to check whether a string is valid Base64 use the Base64 Validator, and to embed a picture use Image to Base64.

Percent-encoding: URLs have their own rules

URLs may only contain a limited set of characters, so everything else is written as a percent sign and two hexadecimal digits. A space becomes %20 and an ampersand becomes %26. The classic bug is using the wrong function. A single query value must have characters such as ampersand, equals sign, question mark and slash escaped, while a whole URL must keep them as they are.

The URL Encoder Decoder offers both behaviors, encodeURIComponent for values and encodeURI for full addresses, plus decoding. For example, the value a&b=c must become a%26b%3Dc inside a query string, or the server reads it as two parameters. Encoding twice turns %20 into %2520, which is the telltale sign of double encoding. To see how a finished link splits into protocol, host, path and query parameters, paste it into the URL Parser.

Hashing: a fingerprint, not a container

A hash function turns any input into a fixed-length fingerprint and cannot be run backward. Change one character of the input and the output changes completely. In hexadecimal the lengths are 32 characters for MD5, 40 for SHA-1, 64 for SHA-256 and 128 for SHA-512. The SHA-256 of the text hello is:

2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Hashes answer the question "is this the same data?" Compare the digest of a download with the one the publisher lists to catch corruption or tampering. Combined with a secret key, a hash becomes an HMAC, which lets a receiver confirm that a webhook or API request came from someone who knows the key and was not altered on the way.

The Hash Generator computes MD5, SHA-1, SHA-256, SHA-384 and SHA-512 for typed text or a file of up to 200 MB, can produce HMACs with your secret key, and does everything in your browser.

Tokens: what a JWT really contains

A JSON Web Token has three dot-separated parts: header, payload and signature. The first two are Base64URL-encoded JSON, so anyone holding the token can read them. The signature proves the token was issued by someone with the key, but only if the receiving server actually verifies it.

The JWT Decoder shows the header and payload, turns the iat, nbf and exp claims into readable dates, says whether the token has expired and flags unsigned tokens that use the none algorithm. Decoding happens in your browser and the token is not sent anywhere. It does not verify the signature, which needs the issuer's secret or public key, so never trust a token merely because it decodes, and never put secrets in a payload.

Identifiers are a related job. The UUID Generator makes random version 4 UUIDs from your browser's secure random source. They carry 122 random bits, which makes collisions practically impossible, but a UUID is an identifier, not a secret.

Encryption: the one that needs a key

Encryption scrambles data so that it can be recovered only with the right key, using algorithms such as AES. None of the tools above encrypt anything. If the requirement is that nobody without the key can read the data, you need a vetted encryption library or a protocol such as HTTPS, never an encoding.

Choosing the right one

• Carry bytes through a text-only channel: Base64, or Base32 when case should not matter.
• Put a value into a URL: percent-encoding.
• Prove a file or message was not changed: a SHA-256 hash, or an HMAC when a shared secret is involved.
• Keep data secret from people without the key: encryption.
• Store a password: a slow, salted password hash, on the server.
• Give a client readable claims: a JWT, with the signature verified on the server.

If the data you are decoding is JSON, fixing invalid JSON covers the syntax errors to expect.