This base64 encoder turns UTF-8 text into Base64 and turns Base64 back into UTF-8 text. The bytes come from TextEncoder. Those bytes are passed through btoa. Decode uses atob and then TextDecoder with fatal mode, so a sequence that is not UTF-8 is an error instead of a silent replacement character.
Two alphabets are on the page. Standard Base64 uses A–Z, a–z, 0–9, +, /, and = padding. URL-safe Base64 uses – and _ instead of + and /, and the encoded result omits padding. Decode in URL-safe mode rejects + / and = so a standard string is not quietly accepted. Decode in standard mode rejects – and _. Switching the select is a deliberate choice.
The page does not call this compression. The encoded form is longer than the UTF-8 bytes, and the status line says how many characters and bytes were involved. It does not call this encryption. There is no key. Anyone who can read the alphabet can reverse it.
Malformed input is rejected. Standard text must use the standard alphabet, keep padding only at the end, and have a length that is a multiple of four. After atob, the page encodes the bytes again and requires the canonical form, so a non-canonical payload is not written out as if it were clean. URL-safe input may omit padding. The decoder adds it only as a temporary step and still checks the canonical padded form. Whitespace and line breaks are ignored on decode so a wrapped block can be pasted. They are not ignored on encode, because spaces in the source text are data.
Empty input is an error in either direction. The limit is 200,000 characters. Unicode such as an accented letter or an emoji is encoded from its UTF-8 bytes, and a round trip returns the same text. That is the check that the page is not treating the string as a row of Latin-1 code units.
Standard encoding of café is the Base64 of the UTF-8 bytes C3 A9 for the last character, not a single Latin-1 byte. Decoding that result returns café. The same text in URL-safe mode uses the other alphabet when the bytes would have required + or /. A string such as @@@ is a useful alphabet check because its standard form contains characters the URL-safe alphabet replaces.
Y2Fmw6k=That sample is the standard encoding of café. If your bytes are an image, this is the wrong page. Image to Base64 reads a JPEG, PNG, or WebP file and can show a data URL. The two tools are related only so you can tell them apart. They do not share an implementation.
A JWT is also Base64URL, but it is three segments and a signature story. This page will encode or decode one block of text. It will not split a token or suggest that a decoded JSON object is authentic. Use the JWT decoder when the input is a token.
Line wrapping is stripped only on decode. If you encode text that already contains line breaks, those breaks are part of the UTF-8 input and they survive a round trip. If you needed the line breaks removed, remove them before you encode. The page will not do that quietly.
The status line reports sizes so you can see that the operation grew the data. If a tutorial told you Base64 would shrink a payload, that tutorial is wrong about this encoding, and this page will not repeat the claim.
UTF-8 text only, via TextEncoder and TextDecoder. Standard uses + / and = padding. URL-safe uses - _ and omits padding. This is not the image data-URL tool, and it is not compression or encryption. Invalid input is rejected. Limit: 200,000 characters.
No. Anyone can decode it. It is a way to write bytes with ASCII characters.
No. The encoded form is longer than the UTF-8 bytes.
Image to Base64 reads image bytes and can build a data URL. This page reads and writes text only.
The alphabet uses - and _ instead of + and /, and this page omits = padding on encode. Decode accepts that form only in URL-safe mode.
