Skip to content
ToolShelf

Base64 encoder / decoder

Encode text to base64 or decode it back, in the standard or URL-safe alphabet, with proper UTF-8 handling and an error that says which character is wrong.

Which way?

Text

Whatever you paste stays in this tab. The work is done by JavaScript in your browser. None of it is uploaded, logged or saved, and the tool keeps working with the network off.

Alphabet

Alphabet

Base64

The encoded result appears here as you type.

Base64 is not encryption

It is worth saying first, because it is the mistake with real consequences. Base64 has no key and keeps no secret. Anything encoded with it can be read back instantly by anyone: on this page, in a browser console, with one shell command. A credential stored base64 “for safety” is stored in plain text with a step in front of it.

What it is for is survival. It turns arbitrary bytes into sixty-four characters that pass unharmed through systems built only for text: email bodies, JSON strings, data URLs, PEM certificates, URL parameters. The problem it solves is mangling, not privacy.

It runs here, in your browser

Both directions are plain JavaScript on this page. Nothing is uploaded, nothing is logged and nothing is stored: load the page, pull the network cable, and the tool still works. Given how often the thing you want to decode is a token or a payload from something real, that seemed worth being able to prove rather than merely assert.

The two alphabets

Standard base64 uses + and / for its last two characters. Both mean something inside a URL, so a value carrying them has to be escaped all over again to travel in one. URL-safe base64 substitutes - and _ and normally drops the = padding, which is the form JWTs and most URL parameters use.

Decoding accepts either without being told which, along with missing padding and the line breaks that wrapped base64 arrives with from openssl or an email header. Only encoding needs the choice, because only then does the tool have to pick.

Text, bytes and the encoding trap

Base64 encodes bytes. Text has to become bytes first, and which bytes depends on the character encoding, which is why an online encoder sometimes disagrees with your code. This tool uses UTF-8 throughout, matching JavaScript, JSON and the web.

It also means the browser’s own btoa is not used here: it works in Latin-1 and throws on any character above U+00FF, so btoa("é") is an error. Going through UTF-8 makes accented text, Chinese and emoji ordinary rather than a special case.

In the other direction, bytes that are not valid UTF-8 are reported rather than printed as replacement characters. Base64 of an image is a perfectly reasonable thing to paste in, and being told it is a file is more useful than a screenful of question marks.

Questions

Is base64 a form of encryption?
No, and this is the most important thing to know about it. Base64 is an encoding with no key and no secret. Anyone can reverse it in a second, including on this page. A password, an API key or a token kept in base64 is kept in plain text with an extra step, and should be treated as readable by anyone who can see it.
What is base64 actually for?
Getting arbitrary bytes safely through systems that only handle text. Email attachments, data URLs in CSS and HTML, binary fields inside JSON, and certificates in PEM files all use it. The point is survival rather than secrecy: the encoded form contains no characters that a text-only channel will mangle.
Is anything I paste here uploaded?
No. Both directions run in JavaScript in your browser and nothing leaves the tab: no request, no logging, no storage. Disconnect the network after the page loads and it still works, which is the quickest way to satisfy yourself that the claim is true.
What is the difference between standard and URL-safe base64?
Two characters. Standard base64 uses + and /, both of which mean something inside a URL and have to be escaped again if you put them in one. URL-safe base64 uses - and _ instead, and usually drops the = padding. JWTs use the URL-safe form. Decoding here accepts either without being told which.
Why does my base64 end in = signs?
Base64 works in groups of three bytes, which become four characters. When the data does not divide into threes, the last group is padded with one or two = to fill the quartet. It carries no information, which is why the URL-safe form usually leaves it off, and this tool decodes fine either way.
Why can it not decode my image?
It decodes it perfectly well, it just cannot show it to you as text. Base64 of a PNG or a JPEG is a sequence of bytes that is not valid UTF-8, so rather than printing a screen of replacement characters the tool says what has happened. Encoded files are a real use of base64; this tool is for the text end of it.
Does base64 make my data bigger?
Yes, by about a third. Every three bytes become four characters, so a 3 MB file becomes roughly 4 MB of base64, plus any line breaks. That overhead is the price of being text-safe, and it is why a large image inlined as a data URL costs more bandwidth than the same image fetched as a file.
Why does an online encoder sometimes give a different answer to my code?
Almost always character encoding. Base64 encodes bytes, not characters, so the text has to become bytes first, and a tool that assumes Latin-1 will produce different output from one that uses UTF-8 for anything outside plain ASCII. This tool uses UTF-8, which is what JavaScript, JSON and the modern web use.

More tools

Developer tools

JSON formatter & validator

Indent it, shrink it, or find out what is wrong with it

{"b":1,"a":[2,3]}Formatted, 2-space indent
Developer tools

URL encoder / decoder

Percent-encoding, with the component and whole-URL rules apart

a b&c=da%20b%26c%3Dd
Developer tools

Robots.txt tester

See which rule a crawler actually applies

A Googlebot group beside a catch-allGooglebot ignores the catch-all