Base64 Encode

What the Base64 encoder does

You have some text, or a small text file, and you need it as Base64. Paste it in, press Convert, and you get the encoded string back, ready to copy or download. That is the whole job.

Base64 is the standard way to take data and rewrite it using only a small set of plain, printable characters, so it can travel safely through channels that were built for text and tend to mangle raw bytes. This tool does the encoding end of that. If you have a Base64 string and want the original back, the Base64 Decode tool runs the same process in reverse.

How to use it

1. Give it your text. Type or paste it into the box, or upload a plain text file with the file picker.
2. Character encoding, if you need it. By default the tool reads your text as UTF-8, which is the right choice almost always. The selector is there for the less common case of text saved in another encoding.
3. Press Convert. The Base64 output appears below, and you can Copy it or Download it as a text file.

Clear wipes the boxes so you can start again.

What Base64 actually is

Think about how data moves around. A lot of the pipes it travels through, email, URLs, the text fields inside JSON, were designed to carry plain text, the kind of characters you can type. Raw binary data is not that. It is full of bytes that those text channels can misread, strip out, or quietly corrupt along the way.

Base64 is the fix. The name is literal: it is a counting system with 64 symbols, the same way decimal has 10 and binary has 2. It takes whatever your data is, down at the level of raw bytes, and respells it using only 64 safe, boring, printable characters that survive the trip through any text channel. Nothing is hidden and nothing is compressed. The data is simply rewritten in an alphabet that travels well.

How the encoding works, step by step

Here is the actual mechanism, and it is worth seeing once because it explains every odd thing about Base64, including those = signs at the end.

Base64 reads your data three bytes at a time. Three bytes is 24 bits. It then re-slices those same 24 bits into four groups of six bits. Each six-bit group is just a number from 0 to 63, and each number picks one character out of a fixed 64-character alphabet. So the rule is simple: every three bytes going in become four characters coming out.

The alphabet is laid out in order: the 26 uppercase letters A to Z are values 0 to 25, the 26 lowercase letters a to z are 26 to 51, the ten digits 0 to 9 are 52 to 61, and the last two, 62 and 63, are + and /. That is 64 characters, all of them plain.

Take the word "Man". Its three letters are the byte values 77, 97, and 110, which in binary are 01001101, 01100001, and 01101110. Stick those together and chop into sixes:

• 010011 = 19 = T
• 010110 = 22 = W
• 000101 = 5 = F
• 101110 = 46 = u

So "Man" encodes to "TWFu". Three bytes in, four characters out, every time.

Now the = signs. Your data will not always divide neatly into three-byte groups. When the last group is short, Base64 fills it out so the output still comes in tidy blocks of four characters, and it marks that filling with = signs. Encode "Hi", which is only two bytes, and you get "SGk=", one = on the end. A single byte on its own ends in two of them. The padding is not part of your data, it is just there to keep the blocks even.

The library doing the work

The encoding here is handled by base64-js, a small, dependency-free JavaScript library and one of the most widely used Base64 packages on npm. It is solid, fast, and the same building block that helps make Buffer work inside browsers. You hand it an array of raw bytes and it hands back the Base64 string.

But there is a step before that which matters more than it looks. Your text is first run through the browser's built-in TextEncoder, which turns it into UTF-8 bytes, and those bytes are what get encoded. The payoff is that accented letters, emoji, Nepali, Japanese, anything outside plain English, all encode correctly. This is the part a lot of quick Base64 code gets wrong. The old shortcut, the browser's btoa function, only understands plain ASCII and chokes the moment you feed it an emoji. Reading the text as UTF-8 first sidesteps that whole class of bug, so you can paste real-world text and trust the result.

What you would actually use it for

Base64 is everywhere once you start looking. A few of the common places:

• Embedding assets in a page. A small image, icon, or font can be dropped straight into your HTML or CSS as a data URI, which is the image's bytes written out in Base64. The browser reads it inline instead of making a separate request for the file.
• Email attachments. Email was built for plain text, so every attachment you have ever sent went out Base64-encoded under the hood. That is the original problem it was invented for.
• Carrying binary inside JSON or XML. Those formats are text and cannot hold raw binary, so when you need to tuck an image or a file into one, you Base64 it into a string field.
• Tokens and headers. JSON Web Tokens carry Base64 chunks, and the HTTP Basic auth header is just a username and password joined and Base64-encoded. Hold that last one in mind for the next section.

One thing Base64 is not

This is the single most important thing to know, because it catches people out and occasionally leaks their secrets. Base64 is not encryption, and it is not security. Anyone can decode it in one step, with no key, no password, nothing. This very site's decoder will do it instantly. Base64 respells your data, it does not lock it.

So never use it to hide anything sensitive. That Basic auth header is the textbook trap: it looks scrambled, but it is your password sitting in plain view to anyone who Base64-decodes it, which is exactly why it is only ever safe when it is also riding inside HTTPS. If you genuinely need to protect data, you want encryption, which is a different thing entirely. And one practical note while we are here: Base64 makes data bigger, by roughly a third, since every three bytes turn into four characters. It is a way to move data safely, never a way to shrink it.

Questions people ask

Is Base64 a form of encryption?

No. It is an encoding, not encryption. There is no key, and anyone can reverse it in one step, so it offers no secrecy at all. Use it to move data through text channels, never to hide it.

Does Base64 make my data smaller?

The opposite. It grows by about a third, because every three bytes of input become four characters of output. It is a transport format, not compression.

Why does my output end in one or two = signs?

That is padding. Base64 works in blocks of three bytes, and when your data does not fill the last block evenly, it adds = signs so the output still lands in neat groups of four characters. It is not part of your original data.

Will it handle emoji and non-English text?

Yes. The tool reads your text as UTF-8 before encoding, so emoji, accents, and scripts like Nepali or Japanese all come through correctly, rather than breaking the way a plain ASCII-only encoder would.

What is the difference between Base64 and Base64URL?

They are nearly the same. Standard Base64 uses + and / as its last two characters, which are awkward inside web addresses. Base64URL swaps those for - and _ so the result is safe to drop into a URL or filename. If you need that version, use the Base64url Encode tool.

References

1. Josefsson, S. (2006). RFC 4648: The Base16, Base32, and Base64 Data Encodings. Internet Engineering Task Force (IETF). https://www.rfc-editor.org/rfc/rfc4648
2. base64-js, a Base64 encoding and decoding library for JavaScript (npm package). https://www.npmjs.com/package/base64-js
3. MDN Web Docs, Base64 (glossary entry and encoding overview). https://developer.mozilla.org/en-US/docs/Glossary/Base64