Base64 encoder and decoder

What base64 actually is

Base64 exists to solve one problem: getting arbitrary bytes through something that only carries text. Email headers, JSON strings, URLs, XML attributes and cookies were all designed for characters, and a raw byte can be a null, a newline, or something a parser treats as the end of the message.

So the bytes are re-written using 64 characters that everything agrees on: A–Z, a–z, 0–9 and two more. Three bytes of input become four characters of output, which is where the roughly one-third size increase comes from. That is the whole idea. There is no key, no secret, and nothing to break.

The bug in most browser base64 tools

JavaScript has a built-in called btoa, and almost every base64 page on the web is a text box wired to it. It has a trap. btoa takes a binary string — one character per byte — so it throws the moment a character goes above U+00FF.

The throw is the honest failure. The dangerous one is the tool that catches it and strips or substitutes the offending characters, because it hands back a valid-looking string that decodes to text you did not write. Nothing on the page tells you it happened.

Text here is encoded to UTF-8 bytes first, and base64 is applied to those bytes — which is what every other language does and what the receiving end will expect. Decoding runs the reverse, strictly, so bytes that are not valid UTF-8 are reported as binary rather than returned as a row of question marks.

Standard, or URL-safe

The standard alphabet ends with + and /. Both are a problem in a URL — / is a path separator and + means a space in a query string — so RFC 4648 defines a second variant that uses - and _ instead.

It also drops the = padding, because = would itself need percent-encoding, which would defeat the point. That is why a JWT has no equals signs in it: each of its three segments is base64url. Decoding here accepts either alphabet, with or without padding, without being told which — there is no way to get that choice wrong.

Data URIs, and when they are a bad idea

A data URI is base64 with a header on the front: data:image/png;base64, and then the bytes. Paste one into a stylesheet and the image is part of the file — no second request, no round trip, nothing to 404.

That is genuinely useful for a 400-byte icon. It is a mistake for a photograph. An inlined image cannot be cached separately, cannot be loaded lazily, blocks the stylesheet or HTML it sits inside, and arrives a third larger than the file it came from. The rule of thumb is a couple of kilobytes: below that, inlining usually wins; above it, a real file almost always does.

Base64 is not encryption

This is worth stating plainly because it is a recurring cause of real incidents. Base64 is a public, reversible, key-less transformation. Anyone who sees the string can read the original in a second — including on this page. Storing a password base64-encoded protects nothing at all.

The confusion is understandable, because encoded text is unreadable to a person, and unreadable feels like safe. It is not the same property. If it must be unreadable to someone holding it, encrypt it. If it must not be recoverable at all, hash it. Base64 is for transport, and only for transport.

Why it runs in your browser

Look at what people actually paste into a base64 decoder: JWTs, API responses, session cookies, config values pulled out of a Kubernetes secret. Every one of those is a live credential or something adjacent to one.

Sending that to a server to have four characters swapped around is an absurd trade, and yet most base64 pages do exactly that. This one converts in the tab, makes no request while you use it, and the Network tab stays empty — which you can check while you paste.

Questions

How do I decode a base64 string?

Paste it in. The direction is picked from what you paste — a string of mixed letters and digits with no spaces is treated as something to decode — and the toggle above the box overrides that guess if it gets it wrong. Nothing is sent anywhere either way.

Why do other tools fail on accented or non-English text?

Because they use btoa, which takes one character per byte and throws on anything above U+00FF. "café" fails, Chinese fails, an emoji fails. Text has to be encoded to UTF-8 bytes first and base64 applied to those bytes. That is what happens here, so every script works — and the worse failure is avoided too: tools that "handle" this by stripping characters return something that looks fine and decodes to different text.

What is the difference between base64 and base64url?

Two characters and the padding. Standard base64 uses + and /, which both have meanings inside a URL, so the URL-safe variant uses - and _ instead and drops the trailing = because it would have to be percent-encoded. Tick "URL-safe alphabet" for that variant. Decoding accepts either without being told which.

Is base64 encryption?

No. It is not encryption, and it is not hashing. Base64 is a way of writing bytes using only 64 characters that survive systems built for text — nothing more. Anyone can decode it, instantly, with no key. If you need something unreadable, encrypt it; if you need something irreversible, hash it.

Why is my encoded string bigger than the file?

Because three bytes become four characters, so base64 is about 33% larger, plus a little for padding and line breaks. That is inherent to the format. It is why a data URI suits a small icon and not a photograph — inlining a 2 MB image costs 2.7 MB of HTML that no browser can cache separately.

Can I base64 a whole file?

Yes — the "A file" tab reads any file in this tab and gives you a complete data: URI you can paste straight into CSS or an <img> tag. Untick the data URI option for raw base64. The file is read locally; it is not uploaded.

It says my base64 decodes to binary. What now?

It means the bytes are not valid UTF-8 text — usually a real file, most often an image. A download button appears, and if the string was a data URI its media type is used to name the file. Showing you replacement characters instead would look like a successful decode of a corrupt file, which is worse than saying so.

What BriskFile will not do to you

• Your files never leave your device

  Every conversion runs in your browser. Open DevTools, watch the Network tab, and you will see no upload — because there is not one.

• No account, no email, no watermark

  Nothing to sign up for and nothing stamped on your images. There is no step between choosing a file and getting it back.

• No limits at the download button

  No daily cap, no file counter, no "upgrade to download". If the tool starts a job, it finishes it.

• Checkable, not just claimed

  Open the Network tab and convert something — nothing goes out. Or load the page, disconnect, and watch it keep working: the tool is already on your machine, and your file never leaves it.