Base64 Encoder / Decoder

Encode text to Base64 or decode Base64 back to text. UTF-8 safe.

Plain text

URL-safe (uses -_ and omits padding)

Base64 output

Base64 input

Decoded text

About Base64

Base64 represents binary data in ASCII characters. Useful for embedding in JSON, URLs or email.
Output is ~33% larger than the input.
URL-safe mode uses - and _ instead of + and /, and omits trailing =.

Frequently asked questions

Why is the encoded output longer than the input?

Base64 represents every 3 bytes of input with 4 ASCII characters, so the encoded form is roughly 33% larger. That overhead is the cost of being able to carry binary safely through text-only channels.

What is URL-safe Base64?

A variant that swaps the + and / characters for - and _, and usually omits padding. It is safe to embed in URLs and filenames without further escaping.

Can I encode an entire file?

Yes. Drop a file into the panel and the entire content is encoded in your browser. Nothing is uploaded, so even large or sensitive files stay local.

Does Base64 provide any security?

No. Base64 is encoding, not encryption. Anyone can decode it trivially. Use real cryptography if you need confidentiality.

What Base64 is, and what it is not

Base64 maps every 3 bytes of data onto 4 characters drawn from a 64-symbol alphabet (A-Z, a-z, 0-9, + and /), padding with = when the input is not a multiple of three. Its purpose is transport safety: binary data survives passage through systems designed for plain text, like JSON payloads, XML, and email. The cost is size... output is always 33% larger than input. Crucially, Base64 is an encoding, not encryption. Anyone can reverse it instantly, so a Base64 string offers exactly zero secrecy; treating it as protection is a genuine security anti-pattern that still appears in production systems.

Where you will meet it

Data URIs: data:image/png;base64,... embeds an image directly into HTML or CSS.
HTTP Basic auth headers encode username:password in Base64 (which is why Basic auth requires HTTPS).
JWT tokens are three Base64url sections joined by dots.
Email attachments travel as Base64 inside MIME, which is why a 10 MB attachment consumes about 13.3 MB of mailbox quota.

The URL-safe variant and other gotchas

Standard Base64 uses + and /, both of which collide with URL syntax, so Base64url substitutes - and _ and usually drops padding. Decoding fails when the two alphabets are mixed, when whitespace or line breaks contaminate the string, or when text was encoded with one character set and decoded with another; for non-ASCII text, always encode the UTF-8 bytes, not a platform default. If a decode produces garbage where you expected text, a charset mismatch is the first suspect.

Recognising and troubleshooting Base64 by eye

Valid Base64 length is always a multiple of 4 (after padding). A string of length 37 cannot be valid; something was truncated.
Zero, one or two trailing = signs are normal; three is impossible.
Seeing - or _ in the string? That is the URL-safe alphabet; convert or use a decoder that accepts it.
Decoded output looks like PHN2Zy... turned into <svg...? You decoded correctly. Output full of replacement characters? Charset mismatch... the bytes are probably fine, the text interpretation is wrong.
Line breaks every 64 or 76 characters are a legacy of email formatting; strip whitespace before decoding.