Base64

Base64 encode and decode online

Type on one side and watch the other, live and in both directions. With accents and emoji handled properly, the URL-safe variant, and a files tab that turns images and PDFs into a data URL ready to paste.

Zero uploads · all in your browser

Neither your text nor your files leave your device: everything is converted right here.

Why it matters that none of this is uploaded

What people paste into a Base64 tool is rarely innocent: an authentication header with a username and password, an access token, a certificate key, a client's logo, an internal PDF. And since Base64 encrypts nothing, sending that string to some random website's server to translate it means handing it over in the clear. Here there is nowhere to send it: your text and your files are converted in your tab and stay there.

How it works, in 3 steps

  1. Pick a side

    Type text on the left and Base64 comes out; paste Base64 on the right and the text comes out. Nothing to click: the tool works out which side you are typing on.

  2. Or drop a file

    In the files tab, drag in an image or a PDF and you get the string, the data URL and the resulting weight. The reverse works too: paste a data URL and download the file.

  3. Copy it

    In whichever shape you need: the bare string, the full data URL, the CSS line or the HTML tag. If the Base64 is broken, we tell you where first.

What Base64 is actually used for

What Base64 actually does

Base64 takes a file or a piece of text and rewrites it using only 64 characters that survive any channel: the 26 uppercase letters, the 26 lowercase ones, the ten digits and the signs + and /. The mechanism is simple: take 3 consecutive bytes, which are 24 bits, and split them into 4 groups of 6 bits; each group of 6 bits is a number from 0 to 63, and that number is a position in the alphabet. When the total is not a multiple of 3, one or two = signs are added at the end so the receiver knows how many real bytes there were.

That gives you the one figure worth remembering: 4 characters for every 3 bytes, meaning 33% more weight. It is not a side effect and it does not depend on the implementation; it is the definition.

So why bother? Because some channels only understand text. Email was born speaking 7-bit ASCII and still works that way underneath; a URL cannot carry arbitrary bytes; a JSON field is a string. Putting the raw bytes of a PNG into any of those destroys them: somewhere along the way something reinterprets a line break or truncates at a zero byte. Base64 is the toll you pay for the data to arrive intact.

Accents and emoji, where half the web falls over

Try typing ñ into any Base64 encoder and you will find a good share of them return something odd, or simply fail. The reason is always the same: they use btoa, the function the browser ships, which only accepts characters from 0 to 255. Give it an ñ and it throws, and the patch that has been circulating for twenty years is btoa(unescape(encodeURIComponent(text))) — built on a deprecated function and broken on emoji, which take two units in JavaScript rather than one.

This tool does not use btoa. Text is first converted to UTF-8 bytes and those bytes are what gets encoded, which is the correct path and the one any system on the other end expects. Decoding does the same in reverse, in strict mode: if the bytes are not valid UTF-8 text you get told, instead of a row of replacement diamonds that you discover once it is already in production. The result is checked against the test vectors in RFC 4648 and against accents, zero-width-joined emoji and Japanese.

When to embed an image and when not to

Turning an image into Base64 exists so you can put it inside the code itself, as data:image/png;base64,…, and save the request. It is a good idea for small files that are needed right away: an icon, a repeating texture, the logo in an email signature — which is exactly why signatures use Base64: the image shows up even when the mail client blocks anything external.

For large files it is a bad idea, for four reasons that stack: it weighs a third more; it travels inside your CSS or HTML, which are the first thing that blocks paint; it is not cached separately, so touching a comma in your stylesheet forces the whole image down again; and it cannot be served in several sizes or in modern formats. A 300 KB photo embedded is nearly 400 KB welded onto your CSS that every visitor downloads whether they see it or not. The practical line sits around 5 to 10 KB, which is why the tool shows you the weight of the data URL with a warning before you copy anything.

If what you actually have is oversized images, this is the wrong place to fix it: that is what the image compressor is for, also without uploading anything.

And if what you need is a fingerprint of some bytes rather than a rewrite of them — the SHA-256 of a file, or the Base64 SHA-384 for an integrity attribute — that is what the hash generator does, also without uploading anything.

When the string is broken, we say where

The browser's atob accepts malformed strings and hands back bytes that are not the ones that were encoded, without a word. Here it is validated properly: if there is a character that does not exist in the alphabet, if the padding sits in the middle, if the length does not add up or if one character is left over, you get told what the problem is, on which line and column, with the offending character highlighted in an excerpt and a button that takes you there.

And there is one case almost no tool checks: a string whose last character leaves non-zero leftover bits. It decodes without complaint, but the bytes that come out are not the ones that went in. It means someone edited it by hand or pasted it badly. You get told about that too.

When the failure has a typical cause, we name it: a string that arrived URL-encoded with %2B and %3D, a whole data URL pasted in, quotes that came along when copying from code, or — the most common of all — a string truncated on its way out of a terminal.

Frequently asked questions

Is Base64 encryption? Does it protect a password?

No, and it is the most widespread misunderstanding about Base64. Encryption means you need a key to get back. Base64 has no key: it is a way of writing the same data with a different set of 64 characters.

Anyone who sees the string can read it in a second. Try it: paste any "secret" Base64 string above and there it is. So a password stored in Base64 in a config file is not protected, only disguised.

The classic example is HTTP Basic authentication, where a username and password travel Base64-encoded in a header. The only thing protecting them there is HTTPS. If you need something nobody else can read, what you want is encryption.

When is embedding an image worth it, and when is it not?

Worth it for small files needed right away: roughly under 5 to 10 KB. Icons, repeating textures, the logo in an email signature, images inside an HTML email that many clients would refuse to fetch from outside.

Not worth it for large files, for four reasons that stack up: it weighs a third more; it travels inside CSS or HTML, which block first paint; it is not cached separately, so changing a comma in your CSS forces the whole image down again; and it cannot be served in several sizes or in modern formats.

A 300 KB photo embedded is nearly 400 KB welded onto your stylesheet that every visitor downloads whether they see it or not.

Why does it grow by about a third?

Because every 3 bytes (24 bits) become 4 characters of 6 bits. Four over three is 1.333: 33.3% more, plus one or two padding characters.

If it is also wrapped at 76 characters, as the email format requires, add another 1.4% for line breaks. The exact formula is 4 × ceil(n/3) characters for n bytes.

Why do other tools mangle my accents and emoji?

Because they use btoa, which only accepts characters from 0 to 255: give it an ñ and it throws. The patch that has circulated for twenty years is btoa(unescape(encodeURIComponent(text))), built on a deprecated function and broken on emoji.

Here the text is converted to UTF-8 bytes first and those are what gets encoded. Reading uses strict mode, so if the bytes are not valid text you are told rather than shown replacement characters.

What is the URL-safe variant?

The standard alphabet ends in + and /, and both mean something inside a URL: the slash separates path segments and the plus reads as a space in query parameters. RFC 4648 defines a variant that replaces + with - and / with _, often without padding.

It is what JWT tokens, many session identifiers and plenty of APIs use internally. A checkbox turns it on, and decoding accepts both without you having to say which one it is.

What are the equals signs at the end for?

They are padding. Since it works in blocks of 3 bytes, when the total is not a multiple of 3 there is a gap: 1 leftover byte adds two =, 2 leftover bytes add one. They tell the receiver how many real bytes there were at the end.

Many implementations drop them, especially in the URL-safe variant. Here you can generate with or without padding, and reading accepts both.

Is my file uploaded to a server?

No. The file is read through the browser's own interface, converted on your machine, and the result stays on the page. No accounts, no database. Load the page, disconnect from the internet and check: it still works exactly the same.

Is there a size limit?

For dropped files, 12 MB. Beyond that, building a string of over sixteen million characters in memory locks up any browser, and we would rather say so.

In practice the useful limit is much lower: if you are considering embedding several megabytes into a page, the answer is almost always that you should not. There is no fixed limit on the text in the split panel.

Why does it say my string is not canonical if it decodes?

Because the last character carries leftover bits that have to be discarded, and those bits should be zero. When they are not, the string still decodes but the bytes that come out are not the ones that went in: it was edited by hand, pasted badly or had a character changed.

Almost no tool checks this: they hand back the bytes silently, which is the worst way to lose data.

Related tools