What next?
Encoding is not hashing, and not escaping. These are the neighbours.
How to use this tool
- Paste your text or Base64 string.
- Choose encode or decode.
- Copy the result.
What your result means
The encoded output is the same data re-spelled in 64 safe characters, roughly 33% longer than what you put in. Nothing has been compressed, protected or altered — decoding returns the original bytes exactly.
That size increase is the thing to weigh in practice. Base64-inlining an image into a data URL saves an HTTP request but makes the payload a third bigger and uncacheable on its own, which is usually a bad trade for anything but tiny icons. And to say it once more: Base64 is not encryption. If the content is sensitive, encrypt it first and Base64 the ciphertext only if it also needs to be text-safe.
Why this one is different
Encoding reports characters in, UTF-8 bytes in, characters out and the size change as a percentage, so the roughly one-third growth is a figure rather than a rumour. Decoding inspects what you pasted first: which alphabet it uses, standard or URL-safe, how much padding it carries, and a message naming the problem when it is not valid Base64 at all.
Why the internet quietly speaks Base64
Email, web tokens and data URLs were built to carry plain text, not raw binary. Base64 solves that by re-packing any data into just 64 safe characters — letters, digits, + and / — so it survives systems that would otherwise mangle it.
One myth worth killing: Base64 is not encryption. It's trivially reversible and hides nothing. It's for transport and compatibility, never for keeping secrets.
Related tools
What Base64 actually does
Base64 takes three bytes of arbitrary binary data (24 bits) and re-expresses them as four printable characters drawn from a 64-character alphabet: A–Z, a–z, 0–9, plus + and /, with = as padding. Because every output character is safe to put in an email body, a URL or an HTML attribute, binary data can travel through text-only channels without being mangled. The cost is size: Base64 output is always about 33% larger than the input.
Worked example
Encoding the text Tool Corner:
Output VG9vbCBDb3JuZXI= (16 characters)
Eleven bytes is not a multiple of three, so the final group is padded — hence the single =. The output is 45% longer here; for longer inputs the overhead settles at about 33%. A single emoji such as 🎉 is four UTF-8 bytes and encodes to 8J+OiQ==.
Frequently asked questions
Is Base64 a form of encryption?＋
No. Base64 is an encoding, not a cipher — anyone can decode it instantly and it provides no confidentiality whatsoever. If you need to protect data, encrypt it first and then Base64-encode the ciphertext if you also need it to be text-safe.
What is the difference between Base64 and base64url?＋
Standard Base64 uses + and / as its last two characters, both of which have special meaning in URLs. The base64url variant defined in RFC 4648 substitutes - and _ so the result can be dropped into a URL or filename unchanged. JSON Web Tokens use base64url.
Does it handle emoji and accented characters?＋
Yes. The text is read as UTF-8 before encoding, so emoji, accents and non-Latin scripts round-trip exactly. A single emoji is four bytes in UTF-8, which is why one character can produce eight Base64 characters.
Why does the output end in one or two equals signs?＋
Base64 works in three-byte groups. When the input length is not a multiple of three, the final group is padded with = so the output length is always a multiple of four. One = means the last group had two bytes, two = means it had one.
How much larger does Base64 make my data?＋
About a third bigger: every three bytes become four characters. That overhead is why inlining large images as data URIs often costs more than it saves.
When is Base64 the right tool?＋
When binary data has to travel through a channel that only handles text safely: email attachments, data URIs, JSON payloads, and tokens in HTTP headers.
Is the conversion done in my browser?＋
Yes. Encoding and decoding happen locally in the page and nothing is sent to a server, which matters if you are inspecting tokens or credentials.
Further reading
Assumptions & limitations
The transform itself is exact. What it is used for is where the assumptions live:
- Base64 is an encoding, not encryption. Anyone can decode it, so it protects nothing.
- Output is about a third larger than the input, which matters for data URIs and payload limits.
- Text is treated as UTF-8 before encoding. Data produced under a different encoding will decode to different bytes.
- Standard and URL-safe alphabets are not interchangeable: a value encoded with one may be rejected by a decoder expecting the other.