Base64 turns up everywhere — email attachments, data URIs, API keys in config files, the middle section of every JWT — and it’s widely misunderstood in one dangerous way. Toolsyy’s Base64 Encode & Decode tool handles the conversion; this guide explains what you’re actually looking at.
What Base64 is for
Plenty of systems can only carry text. Email bodies, URLs, JSON string values, XML documents, HTML attributes — all of them expect printable characters. But the data you want to send is often raw bytes: an image, a PDF, a cryptographic key.
Base64 solves that by re-expressing arbitrary bytes using just 64 safe
characters: A–Z, a–z, 0–9,
+ and /. Three bytes of input become four of those
characters. The result survives any text-only channel and decodes back to
exactly the original bytes.
That’s the entire purpose: transport, not protection.
Base64 is not encryption
This deserves its own heading because it causes real security incidents.
Base64 has no key, no password and no secret of any kind. The transformation is completely public and instantly reversible by anyone — including by pasting it into this page. Encoded text looks scrambled, and that appearance fools people into treating it as protected.
So: never Base64 a password and consider it hidden. Never assume a Base64 blob in a config file or a network capture is safe. If you need something to be unreadable to others, you need actual encryption; if you need to prove a file hasn’t changed, you need a cryptographic hash. Base64 does neither.
The URL-safe variant
Standard Base64 has an awkward problem: two of its characters clash with URL
syntax. + means a space in a query string, and /
separates path segments. The = padding causes trouble too.
The URL-safe variant (RFC 4648 §5) makes three substitutions:
+becomes-/becomes_- trailing
=padding is dropped
This is what JSON Web Tokens use. A JWT is three URL-safe Base64 sections separated by dots — header, payload, signature. Paste the middle section into the decoder and you’ll see the claims in plain JSON, which is a neat illustration of the point above: a JWT payload is signed, so it can’t be tampered with, but it is not secret. Anyone holding the token can read it.
Toolsyy’s decoder accepts either variant, with or without padding, so you can paste a JWT section straight in. Line breaks are ignored too, which helps with Base64 copied out of an email header or a PEM file.
The size cost
Four output characters for every three input bytes means Base64 data is about 33% larger than the original. That’s worth remembering before embedding a large image as a data URI in your CSS or HTML: a 300 KB photo becomes roughly 400 KB of text, it can’t be cached separately from the document, and it can’t be loaded lazily. For small icons the round trip saved is usually worth it; for photographs it rarely is.
Unicode, and why btoa fails
If you’ve tried encoding in the browser console you may have hit this:
btoa("café")
// InvalidCharacterErrorThe built-in btoa only accepts characters below code point 256, so
anything with an accent, an emoji or a non-Latin script throws. The fix is to
convert the text to UTF-8 bytes first and encode those. Toolsyy does this
automatically, so café, 日本語 and 😀 all
round-trip correctly.
FAQ
Is Base64 encryption?
No, and this is the most important thing to know about it. Base64 is a reversible encoding with no key and no secret. Anyone can decode it instantly. Never use it to protect a password, a token or any other sensitive value — it hides data from a casual glance and from nothing else.
What is URL-safe Base64?
Standard Base64 uses the characters plus and slash, which both have special meanings in a URL, and equals signs for padding. The URL-safe variant replaces plus with minus, slash with underscore, and drops the padding, so the result can be placed in a URL or filename unchanged. It is the variant used in JSON Web Tokens.
Why does Base64 make my data bigger?
Base64 represents every three bytes of input as four characters of output, so encoded data is about thirty-three percent larger than the original, plus a little padding. That is the price of being able to carry arbitrary bytes through a channel that only accepts text.
Can Base64 handle emoji and accented characters?
Yes, provided the text is converted to UTF-8 bytes first. This tool does that
automatically, so accents, emoji and non-Latin scripts all encode and decode
correctly. The raw browser btoa function does not, which is why it
throws an error on any character above the ASCII range.
Related guides
- URL encoding explained — the other encoding you meet in query strings.
- How to verify a file checksum — when you need integrity rather than transport.
- How to format and validate JSON — for tidying up a decoded JWT payload.
Try it now: Free Base64 Encoder & Decoder