Base64 Encoder & Decoder

Encode text to base64 or decode it back, in the standard or URL-safe alphabet, with correct handling of Unicode and wrapped lines.

Enable JavaScript to customise; default output below.

Encoding reads the text as UTF-8. Decoding ignores whitespace, so wrapped base64 pastes fine.

Direction
Alphabet

URL-safe swaps + and / for – and _ and drops the padding, so the value survives a query string.

More options Show

0 means one long line. 76 is the MIME line length used in email.

Live preview encoded.txt
SGVsbG8sIHdvcmxk

Output is valid and updates as you type.

Paste text to encode or base64 to decode. Everything runs in your browser, so nothing you paste is uploaded anywhere.

How to use

  1. Choose the direction. Encoding reads your text as UTF-8, which is what every modern system expects.
  2. Pick the alphabet. Standard base64 uses + and /; URL-safe uses - and _ so the value survives a query string or a filename.
  3. Wrap at 76 characters if the value goes into an email header or a PEM style block. Leave it at 0 for anything else.
  4. Decoding ignores whitespace, so base64 copied out of a wrapped email or a JSON file pastes in as it is.
  5. Copy the result, or download it if it is long.

Example

The same three bytes in both alphabets:

Input:      ÿþý
Standard:   w7/DvsO9
URL-safe:   w7_DvsO9

Notice the length: three characters became eight, because each character is two bytes in UTF-8 and base64 grows every three bytes into four.

Pitfalls

  • Base64 is encoding, not encryption. Anyone can decode it, so it hides nothing.
  • It grows the data by about a third. A 3 MB image becomes a 4 MB data URI, which is why inlining large images slows a page down.
  • The standard alphabet contains + and /, which are both meaningful in a URL. A token that breaks when pasted into a link is usually standard base64 in a URL-safe place.
  • Padding is significant to some parsers and ignored by others. JWT drops it; OpenSSL expects it.
  • Decoding arbitrary binary to text cannot work. A decoded PNG is bytes, not characters, and is reported as invalid UTF-8 here.
  • Legacy btoa() in the browser throws on anything outside Latin-1, which is why older tools mangle accented characters.
  • A base64 string whose length is one more than a multiple of four is impossible, whatever the padding, and means the value was truncated.
  • Line breaks inside base64 are legal in MIME and illegal in a data URI. Strip them before building a data URI.

Compatibility

The output follows RFC 4648: section 4 for the standard alphabet, section 5 for the URL and filename safe one. Decoding accepts both padded and unpadded input and ignores whitespace, as RFC 2045 requires for MIME. The tool runs entirely in your browser, and handles inputs up to about a megabyte without blocking the page.

Frequently asked questions

Is base64 secure?
No. It is a way to carry bytes through a text channel. Anything secret needs encryption underneath it.
Why does my decoded text look like rubbish?
Either the input is binary rather than text, or it was encoded in a different character set. This tool decodes as UTF-8.
What is the URL-safe alphabet for?
Query strings, filenames and JWTs, where + and / would be reinterpreted. It also drops the = padding for the same reason.
Do I need the padding?
Only if the consumer expects it. JWTs omit it; most command line tools want it.
Can I encode a file?
This tool takes text. For a file, use base64 -w0 file on the command line, which produces the same output.
Weekly drops

New tools, when there are new tools

One email when something worth using ships. No schedule to fill, so no filler.

Your address goes nowhere else, and one click unsubscribes.