Base64 Encode & Decode

Encode and decode Base64

Pick a direction, paste your text, and the result appears immediately. The swap button sends the result back through as the new input and flips the direction, which is the quickest way to confirm a value round-trips exactly.

Everything happens in your browser. Nothing is uploaded, stored or logged, and the text is deliberately never written into the page address — Base64 routinely carries tokens and credentials, and URLs are saved in browser history and handed to other sites in the referrer header.

What Base64 actually does

Base64 takes arbitrary bytes and rewrites them using only 64 characters that survive being treated as text: A–Z, a–z, 0–9, and two symbols. It exists because a great many systems were built to move text, not bytes, and will corrupt anything that does not look like text.

The arithmetic is simple. Three bytes are 24 bits; 24 bits split evenly into four 6-bit groups; each group indexes one of the 64 characters. When the input does not divide by three, the final group is padded with = to keep the length a multiple of four.

That 3-to-4 ratio is why encoded output is roughly 33% larger than the input. The size readout under the result shows the exact figure for what you pasted.

Base64 is not encryption

This is the single most important thing to know about it, and it is worth being blunt: Base64 provides no secrecy whatsoever. There is no key. The transformation is public, reversible, and undone by any tool on the internet, including this one.

Encoded credentials in a config file, an API token “obscured” as Base64, a Basic Auth header — all of these are readable by anyone who can see them. If a value must stay secret, it needs encryption. Base64’s job is to make data survive transport, not to hide it.

Unicode, and the bug most tools have

Browsers ship btoa for Base64 encoding, and it only accepts characters below U+0100. Call it on “Café” and it throws an error outright.

The usual workaround is to mask each character down to one byte, which stops the error and introduces a much worse problem: every character above U+00FF is silently truncated. The tool produces a plausible-looking Base64 string, and the damage only surfaces later, somewhere else, when it decodes to mojibake.

This tool converts your text to UTF-8 bytes first, then encodes those. “Café”, “Привет”, “日本語” and emoji all round-trip byte-for-byte. Note that the byte count and the character count differ for such text — “é” is one character and two bytes — and the size readout counts bytes, because that is what determines the encoded length.

Standard and URL-safe alphabets

Standard Base64 uses + and / as its last two characters. Both are awkward in a URL, where / is a path separator and + can be read as a space, and awkward in filenames for the same reason.

The URL-safe variant swaps them for - and _. It is what JSON Web Tokens use, which is why JWT segments never need escaping when they appear in a URL. Turn on URL-safe alphabet to produce it. Decoding accepts either alphabet automatically, since no character means one thing in one and something else in the other.

Padding

The trailing = characters carry no data. They exist so the length is always a multiple of four, which lets a decoder work in fixed-size blocks and lets several Base64 values be concatenated unambiguously.

Plenty of formats drop padding entirely — JWTs do — and the value is still perfectly decodable, because the length of the remainder already says how many bytes the last group holds. Turn off Add padding to match those formats. Decoding here accepts padding that is missing, correct, or excessive.

When decoding fails

Two things are genuinely wrong rather than untidy. The first is a character that is not part of either alphabet, which means the value is not Base64 — often a fragment that was cut off, or text that was never encoded.

The second is Base64 that decodes successfully to bytes which are not valid UTF-8 text. That is real Base64 of something binary: an image, a compressed archive, a cryptographic key. There is nothing to display as text, and showing a box of replacement characters would suggest the data was damaged when it is perfectly intact.

Whitespace, line breaks and irregular padding are all accepted silently. MIME wraps Base64 at 76 characters per line, so pasting from an email header or a PEM file brings line breaks with it, and none of them change the underlying bytes.

Frequently asked questions

What is Base64 used for?

It carries binary data through channels that only accept text — email attachments, data: URLs, JSON fields, JWT segments and API tokens. It is an encoding, not encryption: anyone can decode it, and it protects nothing.

Is Base64 encryption?

No, and treating it as such is a genuine security mistake. Base64 is a reversible, keyless transformation that anyone can undo — including this page. It hides nothing. If a value needs to stay secret, it needs encryption, not encoding.

Why does Base64 make my data bigger?

It represents every 3 bytes as 4 text characters, so output is about 33% larger than input, plus up to 2 characters of padding. The tool shows the exact size change under the result.

Does this handle accents, emoji and non-Latin text?

Yes. Text is converted to UTF-8 bytes before encoding, so "Café", "Привет" and emoji all round-trip exactly. This matters because the browser's built-in btoa throws on such text, and the workaround most tools use silently truncates it — producing Base64 that decodes to nonsense somewhere else.

What is the URL-safe alphabet?

Standard Base64 uses + and /, which have their own meaning in URLs and file paths. The URL-safe variant (RFC 4648 §5) uses - and _ instead. Decoding here accepts either without being told which you have.

Why won't it decode my Base64?

Either it contains characters that are not Base64 at all, or it decodes to something that is not text — an encoded image or key, for example. Extra or missing = padding, line breaks and spaces are all accepted, since none of those change the data.

Is my data uploaded?

No. Encoding and decoding happen entirely in your browser. Nothing is uploaded, stored or logged, and the text is deliberately never put in the page address — Base64 is routinely used for tokens and credentials, which have no business in browser history.