How it works
This tool converts text to and from Base64 entirely in your browser. Paste your content into the Input box, then press Encode to turn readable text into Base64, or Decode to turn Base64 back into text. The result appears in the Output box, and the Copy button puts it on your clipboard.
Encoding runs your text through TextEncoder to get its UTF-8 bytes before Base64-ing them, so accented characters, emoji, and other multi-byte content survive the round trip, a common failure point in naive implementations that assume one character equals one byte. Decoding is strict: the tool validates the Base64 and then requires the resulting bytes to be valid UTF-8. If they are not, you will see "Decoded bytes are not valid UTF-8", which almost always means the input was raw binary (an image, a key, a compressed blob) rather than encoded text.
Reading the output
When encoding, a clean string of letters, digits, and + / = (or - _ in URL-safe mode) means success. Trailing = characters are padding, not errors, they signal how many bytes the final group held. When decoding, an Invalid Base64 error usually points to a stray space, a truncated string, or a value that was actually URL-safe: tick the URL-safe box and try again. Because Base64 grows the data, an encoded value is always longer than its source; that is expected, not corruption.
Base64 is encoding, not encryption
Base64 is a reversible encoding that maps arbitrary bytes onto 64 printable ASCII characters. Anyone can decode it instantly with no key, it provides zero confidentiality. Its job is safe transport of binary data through text-only channels, not secrecy. The reference below covers the essentials.
| Property | Detail |
|---|---|
| Alphabet | A–Z, a–z, 0–9, plus + and / (64 symbols), with = for padding |
| URL-safe variant | Replaces + with - and / with _, and usually drops padding, so the value is safe in URLs and filenames without percent-encoding (RFC 4648 §5) |
| Size overhead | Encodes 3 bytes into 4 characters, so output is about 33% larger than the input (4/3), before any line breaks |
| Common uses | Binary-safe transport in JSON and HTTP headers, data: URIs for inline images and fonts, email MIME attachments, and the base64url encoding of JWT segments |
| Confidentiality | None. It is trivially reversible — use TLS or real encryption to protect data |
Frequently asked questions
Is Base64 a form of encryption?
No. Base64 is an encoding, not encryption. There is no key and no secrecy — anyone can decode a Base64 string in seconds. Use it to move binary data safely through text channels, and use TLS or a real cipher when you need to keep something private.
When should I use URL-safe Base64?
Use it whenever the value will live in a URL, query string, cookie, or filename. Standard Base64 uses + and /, which have special meaning in URLs and would need percent-encoding. URL-safe Base64 swaps them for - and _ and drops padding, so it drops straight in — this is the variant used by JWTs.
Why is my Base64 longer than the original text?
Because Base64 represents every 3 bytes of input with 4 output characters, the encoded form is roughly 33% larger. That growth is inherent to the format and is the trade-off for making binary data safe to transport as plain text.
Why do I get a "not valid UTF-8" error when decoding?
This tool decodes Base64 back into text and verifies the bytes are valid UTF-8. If the original data was binary — an image, an encryption key, or a compressed file — those bytes do not form readable text, so the check fails. The Base64 itself may be perfectly valid; it just is not text.
What do the trailing = signs mean?
They are padding. Base64 works in groups of 4 characters, so when the input does not divide evenly into 3 bytes, one or two = characters pad the final group. They are a normal part of standard Base64; the URL-safe variant typically omits them.