Base64 Encode
Encode text to a Base64 string.
How to use the Base64 Encode
- Type or paste your text.
- Copy the Base64 output.
About the Base64 Encode
Base64 is an encoding, not encryption. It offers no security at all — anyone can paste the result into a Base64 decoder and read it straight back. Its real job is representing arbitrary data using a safe 64-character alphabet so it survives systems built only to carry text: email attachments via MIME, data: URIs, images inlined into CSS or HTML, and binary fields tucked inside JSON or XML.
The cost is size. Base64 packs every 3 bytes into 4 characters, so the output runs about a third larger than the input, with = padding on the end to round the length up to a multiple of four. That overhead is precisely why inlining a large image as a data URI is usually a poor trade — you pay 33% extra on every byte to save one request.
This encoder uses the standard alphabet, which includes + and /. It is not the URL-safe variant that swaps those for - and _, so if you need Base64URL, substitute those two characters afterwards. Your text is converted to UTF-8 bytes before encoding, so emoji, accents and non-Latin scripts all encode correctly — a naive btoa() call would simply throw on them. Everything happens in your browser, so pasting a real payload here sends it nowhere.
Frequently asked questions
Is Base64 a way to hide or protect data?
No. It is a reversible encoding with no key and no secret. Anyone who sees the string can decode it in seconds. If you need secrecy, encrypt the data — Base64 is only for making bytes safe to carry through text-only channels.
Why is the output longer than my input?
Base64 represents 3 bytes of data with 4 characters, so it costs roughly 33% more than the raw bytes, plus padding. That overhead is unavoidable — it is the price of using only safe ASCII characters.
Does this produce URL-safe Base64?
No — it uses the standard alphabet with + and /. Both of those have meaning in URLs. To get the URL-safe variant, replace + with - and / with _ in the output, and drop the = padding if your consumer does not want it.
Does it handle emoji and non-English text?
Yes. The text is encoded to UTF-8 bytes first, then Base64-encoded, so anything you can type works. This is the step a plain btoa() skips, which is why btoa() throws on characters above U+00FF.
What are the = signs at the end?
Padding. Base64 works in blocks of 3 bytes, and when the input length is not a multiple of 3 the last block is padded so the output length stays a multiple of 4. You will see one or two = characters, never three.