Base64 Encoder
Encoding turns arbitrary bytes into 64 printable characters so they survive a channel that would otherwise mangle them: an email header, a JSON string, an XML document, a data URI.
This page opens with the encoder selected. Paste text, get Base64, with the conversion happening in your browser.
What happens to your input
The text is first converted to UTF-8 bytes, then those bytes are re-sliced into 6-bit groups and mapped onto the RFC 4648 alphabet. The UTF-8 step is the part naive encoders skip, and skipping it is why so many tools throw or corrupt output the moment you paste an accented character or an emoji.
Three bytes become four characters, so the output is roughly a third larger than the input. Where the input length is not divisible by three, the result is padded with = so its length stays a multiple of four.
Hello → SGVsbG8=
héllo - 世界 🌍 → aMOpbGxvIOKAlCDkuJbnlYwg8J+MjQ==When encoding is the wrong tool
- To hide something - it is trivially reversible with no key. Encrypt instead.
- To shrink something - it grows the payload by a third.
- To put a value in a URL - the standard alphabet contains + and /, which mean something in a query string. Percent-encoding or base64url is what you want.
- To detect corruption - encoding carries no checksum. Hash the bytes instead.
Data URIs are the common destination
Inlining a small image or font into CSS or HTML means Base64-encoding its bytes and prefixing a media type. It removes a network request, which is why it is tempting for icons and tiny assets.
The size penalty is the reason not to overdo it: a third larger, uncacheable separately from the document that contains it, and parsed on every page load. Below about a kilobyte it usually wins; above that it usually does not.