Encode / Decode Base64 Online

Plain text

Base64

URL-safe variant: + becomes -, / becomes _, no trailing =

The conversion happens entirely in your browser: nothing is transmitted — verifiable in your developer tools' Network tab.

01What is Base64 for?

Base64 turns any binary data into harmless text — 64 safe characters (A-Z, a-z, 0-9, + and /) that travel unscathed through anything designed for text: email (MIME attachments), JSON, XML, data URLs (data:image/png;base64,…), HTTP Basic headers. It is not encryption: it is a plain re-encoding, reversible by anyone — as this page proves.

The classic JavaScript trap: btoa("café") throws, because btoa only knows ASCII. This page encodes text to UTF-8 first (TextEncoder), then to Base64 — accents, emoji and ideograms pass unharmed. The segments of a JWT token use the URL-safe variant, decoded here too.

02Understanding the variants

Standard: The historic alphabet (RFC 4648): A-Z a-z 0-9 + / with trailing = padding to align on 4 characters. 3 bytes → 4 characters: +33% volume.
URL-safe: + becomes -, / becomes _, the = padding is usually omitted: the string can live in a URL or filename without escaping. It is the JWT alphabet.
Padding =: Completes the last block so the length is a multiple of 4. Many decoders require it, others do without — this one reconstructs it when missing.
UTF-8: Text must be converted to bytes before encoding: the byte table choice (UTF-8, Latin-1…) is why the same “é” yields different Base64.
data: URI: An image or font embedded directly in HTML/CSS as Base64: handy for small files, counter-productive beyond a few kB (+33% and no separate caching).

03Base64 is not a secret

Passwords, API keys and configurations “protected” with Base64 are a regular sight. Anyone can read them in a second — you just did. The Authorization: Basic header itself is just user:password in Base64: without HTTPS, it is cleartext.

To actually protect data you need encryption (AES, age, GPG…) or, for a stored password, a dedicated hash — see our hashing tool and our password generator.

04Frequently asked questions

Why does my decoded Base64 show weird characters (Ã©, â€¦)?

It is an encoding problem in the original text: the data was encoded as UTF-8 but read back as Latin-1, or vice versa. “é” in UTF-8 is two bytes, which read as Latin-1 display “Ã©”. This page always decodes as UTF-8, today's standard — if the result looks corrupted, the source was probably in another character set.

Is Base64 safe for transmitting a password?

No — it is not encryption, just a rewriting reversible instantly. Its only protection is being unreadable to the naked eye. A password must travel over HTTPS (which encrypts the whole channel) and be stored hashed with a dedicated algorithm (bcrypt, scrypt, argon2), never merely “encoded”.

Why is the encoded version longer than the original?

Base64 represents 3 bytes with 4 characters: an incompressible +33%, plus optional padding. That is the price of carrying only safe characters. For large volumes, send raw binary (HTTP handles it fine) and keep Base64 for contexts that demand text.

How is it different from URL encoding (%20)?

Percent-encoding only escapes the problematic characters of text inside a URL, character by character — the result stays readable. Base64 re-encodes all the bytes, including pure binary, at the cost of readability. JSON in a URL parameter gets percent-encoded; an image in a page goes Base64.