Base64 Encoder & Decoder

Encode text to Base64 or decode it back. Text is converted to UTF-8 bytes first, so Thai, emoji and any other script survive the round trip. Decoding is forgiving: it accepts input with no padding, input broken across lines, and either the standard or the URL-safe alphabet.

Standard and URL-safe alphabets

Base64 needs 64 symbols. Sixty-two of them are uncontroversial: A–Z, a–z, 0–9. The last two are where the two variants disagree, because the obvious choices already mean something inside a URL. Both are set out in RFC 4648.

StandardURL-safe
Symbol 62+-
Symbol 63/_
Padding= to a multiple of 4usually dropped
Safe in a URLNo: + becomes a space, / splits the pathYes
Where you meet itEmail, PEM files, data: URIsJWTs, URL parameters, filenames

Decoding here accepts either alphabet whether or not the box is ticked, and restores missing padding, because input copied out of a JWT or a PEM file frequently has neither.

Why the output is a third larger

Base64 rewrites every 3 bytes as 4 characters, so the result is always about 133% of the input, plus up to two padding characters.

3 bytes  → 4 characters
          100 KB   → about 137 KB
          1 MB     → about 1.37 MB

That is the price of the format, not an inefficiency in it: Base64 exists to carry binary through channels that only accept text, and the growth is what buys that. It is why embedding a large image as a data: URI in CSS is usually a mistake. The file grows by a third and cannot be cached separately.

Base64 is not encryption

It is worth saying plainly, because the two get confused constantly. Base64 is a reversible encoding with no key. Anyone who can read the encoded string can read the original, and every browser has a decoder built in.

Encoding a password, an API key or a token in Base64 hides it from a casual glance and from nothing else. If it needs to stay secret, it needs encryption, and a key you keep somewhere the encoded value is not.

Frequently asked questions

Does it handle Thai text and emoji?

Yes. The text is converted to UTF-8 bytes before encoding. The browser’s built-in btoa() throws on anything outside Latin-1, which is why many Base64 tools fail on the first Thai character.

What is the URL-safe option for?

Standard Base64 uses + and /, which already mean something inside a URL. The URL-safe alphabet uses - and _ instead and drops the padding. Decoding accepts either alphabet whether or not the box is ticked.

Can it decode Base64 that has no padding or has line breaks?

Yes to both. Base64 copied out of PEM files, email headers or JWTs is often wrapped or unpadded, so whitespace is ignored and missing padding is put back.

Is my data uploaded?

No. Encoding and decoding happen in your browser, and the site’s security policy sets connect-src ‘none’, so the browser blocks network requests from these pages.