Base64 Encoder / Decoder Developer Tool

What Base64 actually does

Base64 is a binary-to-text encoding: it takes arbitrary bytes and represents them using only 64 printable ASCII characters (A–Z, a–z, 0–9, plus + and /, with = used for padding). It works by grouping the input into 6-bit chunks — since 2⁶ is 64 — and mapping each chunk to one of those 64 characters. The result is text that any system expecting plain ASCII or UTF-8 can carry safely, even if the original bytes included control characters, null bytes, or anything else that would corrupt a text-only channel.

It is worth debunking a common misconception directly: Base64 is not encryption, and it provides no confidentiality whatsoever. Anyone can decode it back to the original bytes with no key, password, or secret involved — it's a reversible, publicly known transformation, not a cipher. Seeing a Base64-looking string in a config file, a JWT, or a URL should never be mistaken for the data being protected. If you see credentials or sensitive data Base64-encoded, treat them as being sent in plain text, because functionally they are.

Why it exists

Base64 dates back to early email systems, where MIME needed a way to attach binary files (images, documents) to messages built on protocols that only reliably carried 7-bit ASCII text. Encoding the attachment as Base64 let it travel through mail servers that would otherwise mangle raw binary. That same underlying problem — a text-only channel needing to carry binary data — recurs constantly in modern development: embedding a small image directly in CSS or HTML via a data URI (data:image/png;base64,...) avoids an extra HTTP request, and embedding binary data inside JSON or XML documents (which have no native binary type) requires encoding it as text first. It's also how binary payloads get carried safely inside URLs, cookies, and other contexts that don't tolerate arbitrary bytes.

The size overhead

Base64 isn't free: every 3 bytes of input become 4 characters of output, since 3 bytes (24 bits) split evenly into four 6-bit groups. That's a fixed 33% increase in size, plus a little more for line breaks in some contexts and up to two padding = characters at the end when the input length isn't a multiple of 3. For small strings the overhead barely matters, but it's worth knowing before embedding a large file as a Base64 data URI instead of just linking to it, since the encoded version will always be noticeably larger than the original.

URL-safe Base64

Standard Base64's + and / characters both have special meaning inside URLs and query strings, which forces extra percent-encoding if you try to put standard Base64 output directly into a URL. A variant called Base64URL replaces + with - and / with _, and typically drops the = padding entirely, producing a string that's safe to use unescaped in a URL path, query parameter, or filename. It's the encoding used inside JWTs and many other web tokens for exactly this reason. This tool produces standard Base64; if you need the URL-safe variant, the two extra character substitutions are simple to apply afterward.