About this tool
This free Base64 encoder / decoder converts text to and from Base64. It is UTF-8 safe, so emoji, accented letters, Chinese, Japanese, Korean, Arabic and Cyrillic all survive the round trip intact — which is more than can be said for a surprising number of Base64 tools.
Everything runs in your browser. Nothing you paste is uploaded, logged or seen by anyone, which matters more here than on most tools: people paste API keys, tokens and config fragments into Base64 converters all day long.
What Base64 actually is
Base64 is not encryption. It is not compression either. It is a way of rewriting *any* data using only 64 characters that are safe to send almost anywhere: A–Z, a–z, 0–9, + and /, with = used as padding at the end.
The reason it exists is historical and still relevant. Many systems were built to carry text, not arbitrary bytes — email bodies, JSON string fields, XML attributes, HTTP headers, URLs, environment variables. Hand those systems a raw byte like 0x00 or 0x1B and something along the way will mangle it, strip it, or refuse the message. Base64 sidesteps the whole problem by turning those bytes into ordinary letters and digits that nothing objects to.
The mechanism is simple: Base64 takes your data 3 bytes at a time (24 bits) and rewrites it as 4 characters (6 bits each). That ratio is why Base64 output is always about 33% larger than the input. When the data does not divide evenly into 3, the final group is padded with one or two = characters.
Base64 is not a secret
This is worth being blunt about, because it causes real security incidents.
Anyone can decode Base64. There is no key, no password, no secret. This very page will decode it in an instant, and so will every developer, every log scanner and every attacker who finds it. cGFzc3dvcmQxMjM= is not a hidden password — it is the word password123 wearing a very thin disguise.
So: Base64 is fine for transport. It is not, and has never been, a way to protect anything. If you need something to stay unreadable, you need actual encryption. The fact that a value *looks* scrambled is not the same as it *being* protected.
This cuts the other way too, and usefully: if you find a long run of letters and digits ending in = in a log file, a config or a URL, it is very likely Base64 — and you can simply read it.
Where you will meet it
- Data URLs — data:image/png;base64,iVBORw0KGgo… embeds an image directly in HTML or CSS, with no separate file to fetch
- HTTP Basic auth — the Authorization header is literally username:password in Base64, which is exactly why Basic auth without HTTPS is unsafe
- JSON Web Tokens — a JWT is three Base64url chunks joined by dots; the first two are plain readable JSON
- Email attachments — MIME has used Base64 to carry binary files through text-only mail systems for decades
- Config and secrets files — Kubernetes secrets, .env files and CI variables often store values Base64-encoded, again for transport rather than safety
- APIs — any field that must carry binary data inside a JSON string
UTF-8, and why some tools get it wrong
Base64 encodes bytes, not characters. So before anything can be encoded, text has to be turned into bytes — and that step is where tools quietly break.
The classic bug is using a byte-per-character conversion on text that contains anything outside plain ASCII. Paste café or 日本語 or an emoji into a tool written that way and you get an error, or worse, silently corrupted output that decodes back as mojibake.
This tool converts your text to UTF-8 first, which is the encoding the web actually uses. é, →, 🎉 and 한국어 all encode and decode back exactly as you typed them.
Standard Base64 and Base64url
There are two flavours, and mixing them up is a common source of "that isn't valid Base64" errors.
Standard Base64 uses + and / for its last two characters. That is what this tool produces, and what almost everything expects.
Base64url swaps those for - and _, and usually drops the = padding. It exists because + and / have their own meanings inside a URL and a file path, so they would need escaping. JWTs use Base64url, as do many APIs that put encoded values in a path or query string.
If a decode fails on a string full of - and _, that is why. Swapping them back for + and / will usually fix it.
How to use it
- Paste your text (or Base64) into the box
- Encode or Decode with the buttons
- Swap to move the result into the input and go the other way
- Copy the result
Good to know
- Base64 output is ~33% bigger than the input. A 3 MB image becomes roughly 4 MB as a data URL — worth remembering before inlining large files.
- Whitespace is usually harmless. Many systems wrap Base64 at 76 characters per line; decoders normally ignore the line breaks.
- = only appears at the end, never in the middle. One or two of them, never three.
- Length is always a multiple of 4 once padding is included. If yours is not, something has been truncated.
- Decoding arbitrary binary back to text will look like nonsense. If you Base64-decode a PNG you get bytes, not words — that is correct, not a failure.
Common questions
Is Base64 encryption?
No, and this is the single most important thing to know about it. Base64 has no key and no secret. Anyone who sees the string can decode it in one step, including this page. It is an encoding for safe transport, not a protection. Never use it to hide a password, a token or anything else that matters.
Why does my Base64 end with one or two equals signs?
That is padding. Base64 works on groups of 3 bytes, which become 4 characters. When your data does not divide evenly by 3, the last group is short and is padded out with = so the total length stays a multiple of 4. One leftover byte gives ==, two leftover bytes give =, and an exact multiple gives no padding at all.
Why is my Base64 string longer than the original?
Because every 3 bytes become 4 characters, output is always about 33% larger than input, plus up to two padding characters. This is unavoidable and is the price of making arbitrary data safe to put in a text field. If size matters, compress the data before encoding it, not after.
Can I Base64 encode an image or a PDF?
Yes, and that is a common use — it is how data URLs embed images in HTML and CSS. This particular tool works on text you paste, so it suits tokens, JSON, config values and existing Base64 strings. Remember the 33% size increase before inlining anything large.
Why does my decode fail with "isn't valid Base64"?
The usual causes are a truncated string, stray characters pasted along with it, or Base64url. Base64url uses - and _ where standard Base64 uses + and /, and often has its padding removed — so a JWT chunk pasted straight in may not decode. Swap - for + and _ for / and try again.
Does my text get sent to a server?
No. The whole conversion happens in your browser using its built-in functions. Nothing is uploaded and nothing is stored, which is why the tool keeps working with your connection switched off. Given how often people paste credentials into Base64 tools, that is the point.
Related tools
- URL Encoder / Decoder — the other encoding you meet constantly in URLs and query strings
- JWT Decoder — reads the Base64url chunks of a token for you, no manual swapping
- Hash Generator — MD5, SHA-1 and SHA-256, which unlike Base64 are one-way
- Image to Base64 — turn an actual image file into a data URL
