Base64 encode and decode, files included
Type or paste into the panel above and the base64 appears as you go, or choose a file and get the base64 of its actual bytes, which is what makes a picture survive the trip and come back the same picture. Decoding works the other way and tells you what came back: the number of bytes, whether it reads as text, and what kind of file it looks like if it does not. The URL-safe alphabet, the padding and data URI wrapping are all switches rather than assumptions.
Base64 that survives a file, not just a sentence
Text one way and back the other, and a file too: this works on the bytes rather than on characters, so a picture survives the round trip and comes back the same picture, and an accented letter does not stop it dead the way the usual one-line version does.
Whatever you paste or open here stays in this tab: the encoding runs beside the box and there is no code in this page that could send it anywhere. Worth saying plainly, because base64 looks like a code and is not one: it is a way of writing bytes down using sixty-four characters that survive email and URLs, and anybody who has the string has the file.
Base64 encoder and decoder, step by step
- Pick a directionEncode takes text or a file and gives you base64. Decode takes base64, in either alphabet, with or without padding and data URI and all.
- Put something inThe text box works as you type. The file button reads the file in pieces, so a large one does not freeze the tab while it is being read.
- Set the switches if you need themURL-safe for anything going into a query string or a filename, padding off where a parser insists on it, and the data URI wrapper for a stylesheet or an image tag.
What btoa gets wrong, and why this works on bytes instead
Browsers have had a base64 encoder built in for twenty years, and almost every tool of this kind is a thin wrapper around it. The trouble is what it is defined on. Both halves work on what the specification calls a binary string: one character per byte, every code point below 256. Hand the encoder a string with an accented letter or an emoji in it and it throws, which is why so many of these pages fall over on ordinary European text. Hand the decoder something that came from a picture and it returns a string whose characters are byte values, which is not text in any encoding, and the pages that then display it produce a screen of replacement characters and offer it to you as your data. Everything here works on arrays of bytes from end to end. Text is turned into bytes as UTF-8 on the way in and back from bytes on the way out, and a file skips that step entirely because a file was never characters in the first place. Decoding refuses anything malformed by name rather than dropping what it does not recognise, because a decoder that quietly ignores stray characters hands you a file that is subtly not the one you had.
Base64 is one of those things that everybody uses and nobody looks at directly. It is how a small image gets inlined into a stylesheet, how an attachment travels through email, how a key or a certificate is written down in a file you can open in a text editor. All it does is write bytes using sixty-four characters that survive being treated as text, which sounds trivial until you consider how many systems in the middle would otherwise mangle them.
The reason there are several hundred pages offering to do it and this one exists anyway is that most of them cannot do files. That is not an oversight, it is inherited: the browser’s own encoder works on characters rather than bytes and falls over on anything above the Latin-1 range, so a page built on it can encode a sentence in English and not much else. Feed one an emoji and watch.
Working on bytes fixes both ends at once. A file is bytes to begin with, so it goes straight through, and text becomes bytes as UTF-8 first, which is what every other system means by the text of a string. It also means the round trip is genuinely lossless: encode a PNG here, decode the result, and you get back a file that is identical byte for byte, which is asserted on every build rather than asserted in this paragraph.
One last thing worth saying, because the misconception is common enough to be a security problem. Base64 is not encryption and it is not obfuscation. It is an encoding, exactly like writing a number in hexadecimal is an encoding, and reversing it takes one line in any language and no key at all. If you find something base64 in a configuration file, you have found the value, not a protected version of it.
Questions
Why does my base64 have equals signs on the end?
That is padding. Base64 works in groups of three bytes, which become four characters, and a message whose length is not a multiple of three leaves a group short. The equals signs make the output a multiple of four so a decoder knows how many bytes the last group really held. Some parsers insist on them being there and a few insist on them being gone, which is why it is a switch here rather than a decision made for you.
What is the URL-safe alphabet for?
Standard base64 uses plus and slash as two of its sixty-four characters, and both mean something else in a URL, where a slash separates path segments and a plus is sometimes read as a space in a query string. The URL-safe variant swaps them for minus and underscore, which pass through untouched. It is what JSON Web Tokens use, and it is what you want for anything that will end up in a link or a filename.
Can I paste a data URI straight in?
Yes. If what you paste starts with the data scheme and says base64, the prefix is recognised, the media type is read off it and reported back to you, and only the part after the comma is decoded. A data URI that is not base64 at all, which is a legal thing to write, is refused rather than treated as though it were, because decoding that would produce confident nonsense.
Is base64 a way of hiding something?
No, and it is worth being blunt about because people do treat it as one. It is a way of writing arbitrary bytes using sixty-four characters that survive email, URLs and anything else that expects text. There is no key and no secret. Anybody who has the string has the contents, and every browser and every programming language can turn it back in one line. Encoding a password in base64 protects it from nothing at all.
How big a file can it handle?
Larger than you would expect, because it is read and encoded in pieces rather than all at once, but the result is a string and the string has to live in memory. Base64 is also about a third bigger than what went in, so a ten megabyte file becomes about thirteen and a half megabytes of text. That is fine. A very large video is not, and the honest answer is that base64 is the wrong tool for one anyway.
Other things here
There is a full list on the free tools page. They all work the same way: in the browser, with nothing to install.