Base64 encode text online
Type or paste anything and get its Base64 form as you go. The input is converted to UTF-8 bytes first, so accented letters, Greek, Chinese and emoji all encode correctly instead of throwing the error you get from a plain btoa call.
Everything is encoded inside this browser tab. Nothing you paste is uploaded to a server or stored anywhere — close the tab and it is gone.
How Base64 encoding works
Base64 rewrites arbitrary bytes using 64 characters that survive being pasted into places which expect text: A–Z, a–z, 0–9, plus and slash. It works three bytes at a time. Those 24 bits are sliced into four groups of six, and each six-bit group picks one character from the alphabet. When the input length does not divide by three, the final group is padded with zero bits and one or two = characters are appended, so a decoder knows how many bytes to discard at the end.
The step most tools skip is the one before that. What you typed is not bytes yet — it is a sequence of Unicode characters, and something has to decide how those become bytes. This page uses UTF-8, the encoding the web settled on: A is one byte, é is two, 中 is three, an emoji is four. That is why the byte count under the output is often larger than the number of characters you typed, and why the growth figure moves around on short inputs.
Four output characters for every three input bytes is where the overhead comes from: the result is four-thirds the size, roughly 33% larger, plus up to two padding characters and any line breaks you add. Nothing is compressed and nothing is concealed. If the payload needs to be smaller, compress before encoding rather than after — Base64 output has almost no redundancy left for a compressor to find.
Questions about encoding to Base64
Why is the output about a third bigger than the input?
Because six bits of information are being carried by a character that occupies eight. Three bytes in, four characters out, so the ratio is exactly 4:3 before padding — 300 bytes become 400 characters, and 301 bytes become 404 once padding is added. Wrapping adds a newline every 76 characters on top of that. This is the price of the format rather than something a better tool could avoid: any encoding restricted to 64 safe characters pays it. The line under the output shows the real figure for your input, which drifts away from 33% on short strings because padding is a larger share of a small result.
What is the difference between standard and URL-safe Base64?
Standard Base64 uses + and / as its final two characters. Both mean something else in a URL: / separates path segments, and + is read as a space by anything following form-encoding rules. URL-safe Base64, defined in RFC 4648 section 5, swaps them for - and _ and normally drops the = padding, because = has its own job in a query string. Tick the box when the result is going into a path, a query parameter, a cookie or a JWT. Leave it clear for email attachments, PEM keys, data URIs and anything else that expects the standard alphabet.
When should I wrap the output at 76 characters?
MIME, defined in RFC 2045, requires lines no longer than 76 characters in mail bodies, which is why a Base64 attachment arrives as a tall narrow block of text. Wrap when you are assembling an email part, an S/MIME body or a PEM-style file by hand — though PEM itself conventionally uses 64 characters, not 76. Do not wrap when the value goes into JSON, an HTTP header, a URL or a data URI: the newlines are not part of the data, and a strict decoder is entitled to reject them. Most decoders ignore whitespace, but that is a courtesy you cannot depend on.
Does Base64 encrypt or hide anything?
No, and this catches people out regularly. Base64 is a transport format, not a cipher. There is no key, and decoding is a one-line operation available in every language and in any browser console. A password stored as Base64 is stored in plain text with an extra step in front of it. Where the format belongs is anywhere the channel is hostile to raw bytes: an image inlined into CSS as a data URI, a binary blob in a JSON field, a certificate pasted into a configuration file. Use TLS for privacy in transit and real encryption for privacy at rest.
Why do emoji and accented characters break other Base64 tools?
The browser's built-in btoa accepts a string whose every character sits below U+0100 and throws an InvalidCharacterError on anything else, because it has no way of knowing which encoding you meant. A tool built on btoa alone therefore works until the first é, ß or emoji and then stops with an error, or worse, silently mangles the text. This page runs the input through TextEncoder first, so what reaches the encoder is already UTF-8 bytes. Paste the result into the decode page and you get back exactly what you typed, emoji included.