Base64 Encoder & Decoder

How Base64 works

Computers store everything as bytes: numbers from 0 to 255. Many systems, such as email, JSON, URLs and HTML, only handle plain text safely. Base64 solves this by writing any bytes using 64 safe characters: A–Z, a–z, 0–9, + and /.

The trick is to regroup the bits. Three bytes hold 24 bits. Base64 cuts those 24 bits into four groups of 6 bits. Each 6-bit group is a number from 0 to 63, and each number maps to one character. So every 3 bytes become 4 characters.

Worked example: “Man”

Joined together, the bits are 010011 010110 000101 101110. Those four groups are 19, 22, 5 and 46, which are the characters T, W, F and u. So “Man” encodes to TWFu.

Padding with =

When the data is not a multiple of 3 bytes, the last group is filled with zero bits and marked with =. “Hi” is 2 bytes, so it becomes 3 characters plus one =: SGk=. A single byte such as “M” becomes TQ==. The padding tells the decoder how many bytes the last group really holds.

Text, UTF-8 and emoji

Base64 encodes bytes, not letters, so text has to become bytes first. This tool uses UTF-8, the standard on the web. That means every language and every emoji works:

• “é” is two bytes in UTF-8 (C3 A9), so it encodes to w6k=.
• “😀” is four bytes, so it encodes to 8J+YgA==.

This matters because JavaScript’s built-in btoa() only accepts Latin-1 characters. Feed it an emoji or Chinese text and it throws an error. Tools built on it either fail or quietly produce the wrong bytes.

Which Base64 do you need?

Pick URL-safe when the result goes into a web address, because + and / have special meanings there. Pick a line length only when a format demands it, such as a -----BEGIN CERTIFICATE----- block.

What the decoder accepts

Real-world Base64 is often messy. The decoder handles the common cases for you and tells you what it found:

• Line breaks and spaces, for example text copied from an email or a PEM file.
• Missing padding, which is normal for URL-safe Base64 and JWT parts.
• Data URLs such as data:image/png;base64,iVBORw0KGgo…. The MIME type is read from the prefix.
• URL-encoded characters (%2B, %2F and %3D), which appear when Base64 was pasted into a link.

When something is genuinely wrong, the error names the first bad character and its position. A common mistake is copying the text with quotation marks around it. Another is a string that was cut short: Base64 can never have exactly one character left over in its last group, so the tool flags that too. If you paste a JWT, it recognises the three dot-separated parts and tells you to decode them one at a time.

Files and data URLs

Switch to File to turn any file into Base64 or a data URL. A data URL bundles the type and the data together, so you can paste it straight into HTML or CSS. That is handy for small icons, because the page needs one request fewer. For bigger images it backfires: Base64 is a third larger and the browser can’t cache the image separately. Keep data URLs for files of a few kilobytes.

Decoding works the other way. If the Base64 holds a file rather than text, the tool reads its first bytes, the “magic number”, to recognise it. A PNG always starts with the bytes 89 50 4E 47, a PDF with %PDF and a ZIP with PK. You get a preview for images and a download with the right file extension.

Tips and common gotchas

• Base64 is not encryption. Anyone can decode it instantly. Never use it to hide a password or an API key; generate a strong secret with the password generator instead.
• Watch for hidden line breaks. On Linux and macOS, echo "hello" | base64 gives aGVsbG8K, because echo adds a newline. Plain “hello” encodes to aGVsbG8=. Use printf or echo -n to match.
• Check a decoded file. To confirm a decoded download matches the original, compare checksums with the hash generator.
• Decoded JSON? Paste it into the JSON formatter to read and validate it.

Everything happens in your browser. Your text and files are never uploaded, so the tool is safe for tokens, keys and private documents.