Base64 Encode and Decode: A Practical Guide

To encode text to Base64, paste it into the box, choose Text to Base64, and press Run. To go the other way, switch the direction to Base64 to text and paste the encoded value. Both directions run in your browser, handle UTF-8 correctly, and report the input and output lengths.

Base64 is one of those formats that looks like encryption and is not. It is a way to represent arbitrary bytes using 64 printable characters, so binary data can travel through systems that only accept text. Anyone can reverse it. Treat the output as encoding, never as protection.

#What the tool does

• Encode takes the input as UTF-8 text, converts it to bytes, and produces standard Base64 with +, / and = padding.
• Decode removes whitespace, validates the alphabet and padding, and converts the bytes back to text.
• UTF-8 handling means accented characters and emoji survive a round trip. A character outside ASCII is more than one byte, so it also produces more Base64 output than a naive character count suggests.
• Length reporting shows both characters and bytes, which is useful when you are checking a payload against a limit.

The conversion is local. The input may be a credential, a token or a connection string, and none of those should be uploaded to encode them.

#How to encode or decode Base64

1. Open the Base64 encoder.
2. Choose the direction: Text to Base64 or Base64 to text.
3. Paste the input.
4. Press Run.
5. Copy the output.

There is one input box, because the direction determines how it is interpreted. The tool does not try to guess whether your text is plain text or Base64; that ambiguity is exactly what a direction switch resolves.

#What valid Base64 looks like

Standard Base64 uses:

• A–Z, a–z, 0–9, + and / for data.
• = at the end as padding, at most two characters.
• A length that is a multiple of four after whitespace is removed.

Encoding 3 bytes produces 4 characters. Encoding 1 byte produces 2 characters plus ==; encoding 2 bytes produces 3 characters plus =. That is why the output is roughly a third larger than the input.

The decoder strips spaces, tabs and line breaks before validating. That is deliberate: MIME encoders and editors wrap long Base64 lines, and rejecting a wrapped value would be unhelpful. Whitespace inside the alphabet is not data, so removing it is safe.

#Common problems and fixes

"Only letters, digits, +, / and trailing = are allowed." The input contains a character outside the standard alphabet. A URL-safe token uses - and _; convert those to + and / first, or use a URL-safe decoder.

"Length must be a multiple of four." Characters were dropped, or padding was removed. Add the missing = padding or restore the full value.

"Padding does not match." The length is right but the = count is wrong for the data. The value is likely truncated at the end.

"Those bytes decode, but not to valid UTF-8 text." The Base64 represents binary data — an image, a compressed file or encrypted bytes — not text. This tool decodes text, so it refuses to print mojibake. Use a binary-aware decoder for files.

The decoded text looks like gibberish. It may be encrypted data or a different character encoding. Base64 does not describe what the bytes mean; it only represents them.

The output is longer than I expected. Base64 adds about 33 percent, and UTF-8 multi-byte characters add more. That is normal.

A JWT will not decode here. JWTs use Base64URL, which replaces + and / with - and _ and usually omits padding. Use the JWT decoder for tokens.

The + character turned into a space. That happens when Base64 is passed through a URL or form without encoding. The + must be percent-encoded as %2B in a query string.

#Base64, Base64URL and other variants

This tool implements standard Base64. If you are working with JWTs or URL-safe identifiers, the characters differ and decoding will fail until you translate them. That is a feature: a silent conversion could hide a broken token.

#What Base64 is good for

• Embedding small binary assets in text. A data URI such as data:image/png;base64,... carries an image inside HTML or CSS.
• Transporting bytes through text-only systems. Email attachments, JSON fields that must be strings, and configuration values.
• Avoiding delimiter conflicts. A value that may contain newlines or quotes can be encoded and safely embedded.
• Storing a small key or certificate in an environment variable. PEM files are Base64 wrapped in header and footer lines.

#What it is not good for

• Protecting secrets. Base64 is reversible by anyone. It is not encryption and adds no security.
• Compressing data. It makes data larger, not smaller.
• Hiding credentials in a URL. The value is trivially decoded, and URLs are logged.
• Encoding large files for a web page. Inline data URIs bypass caching and inflate the document. Use a real file and a URL.

If you need confidentiality, use encryption with a key. The ChaCha20 encryption tool is the relevant primitive; Base64 is at most the transport encoding around it.

#Tips for working with encoded values

• Keep the padding. Removing = is common in URLs but breaks standard decoders.
• Do not wrap manually. The decoder tolerates line breaks, so let the source wrap naturally.
• Check the length. A Base64 string whose length is not a multiple of four has been truncated.
• Encode the bytes, not the characters. If you are writing code, encode a byte array. Encoding a string in the wrong charset is the usual cause of corrupted accented text.
• Use the right variant. Standard for text and data URIs, URL-safe for tokens and query parameters.
• Never paste production secrets into a tool you do not trust. This one runs locally, but the habit matters.

#Frequently asked questions

#Bottom line

Base64 is a transport format: useful for carrying bytes through text-only channels, useless as a security measure. This tool handles the standard alphabet, UTF-8 text and wrapped input, and tells you clearly when the bytes are not text. Start with the Base64 encoder, and use the JWT decoder when the value is a token rather than plain encoded text.