Base64 Encoder / Decoder

What is Base64 encoding?

Base64 is a binary-to-text encoding that represents arbitrary data using a 64-character alphabet (A–Z, a–z, 0–9, + and /). It lets binary content move safely through channels designed for text, such as email, JSON, XML, and data: URIs.

How to use this tool

1. Paste your text into the Input box.
2. Click Encode to Base64 to convert it, or Decode from Base64 to reverse it.
3. Use Copy output to grab the result.

The tool encodes via UTF-8, so Unicode text and emoji round-trip correctly.

Where Base64 came from

Base64 was born from a very specific problem: the early internet moved mail as plain 7-bit ASCII text. The original Simple Mail Transfer Protocol (SMTP) assumed every byte fit in seven bits, and many mail relays would strip the eighth bit, mangle control characters, or rewrite line endings. Raw binary — an image, a program, a compressed archive — could not survive that journey intact. What was needed was a reversible way to disguise arbitrary bytes as ordinary letters and digits.

The encoding first appeared in Privacy-Enhanced Mail (PEM), published as RFC 1421 in February 1993, where it wrapped encrypted message bodies in printable text. It reached a far wider audience through MIME (Multipurpose Internet Mail Extensions), whose Part One, RFC 2045, was published in November 1996 and defined Base64 as a standard Content-Transfer-Encoding for email attachments. The modern, consolidated specification is RFC 4648, "The Base16, Base32, and Base64 Data Encodings" (October 2006), which obsoletes the earlier RFC 3548 and is the document most software follows today.

How Base64 encoding actually works

Base64 processes the input three bytes at a time. Three bytes are 24 bits, and 24 divides evenly into four groups of six bits. Each 6-bit group — a sextet — holds a value from 0 to 63, which is exactly enough to index a 64-character alphabet. So every 3 input bytes become 4 output characters, and the output uses only safe, printable symbols.

The 64-character alphabet, in order, is:

• A–Z for the values 0–25
• a–z for the values 26–51
• 0–9 for the values 52–61
• + for 62 and / for 63

A worked example makes it concrete. The three letters Man are the bytes 77 97 110, or in binary 01001101 01100001 01101110. Regrouped into sextets that becomes 010011 010110 000101 101110 — the values 19 22 5 46 — which map to T W F u. So Man encodes to TWFu. Decoding simply reverses the steps: four characters back to four sextets, concatenated into 24 bits, then sliced back into the original three bytes.

Inputs are rarely an exact multiple of three bytes, so Base64 uses the = character as padding to record how many real bytes the final group held:

• A complete group of 3 bytes → 4 characters, no padding.
• 2 leftover bytes (16 bits) → 3 characters plus one =.
• 1 leftover byte (8 bits) → 2 characters plus two ==.

The padding is not decorative: it tells the decoder to discard the extra zero bits that were added to fill out the last sextet, so the original byte count is restored exactly.

The 33% size overhead, explained

Because every 3 bytes turn into 4 characters, Base64 output is always about four-thirds (4/3) the size of the input — roughly a 33% increase. The exact figure depends on the input length, its remainder when divided by three (padding rounds the last group up to four characters), and whether line breaks are inserted. A 9 KB file becomes about 12 KB of text; a 3 MB image becomes about 4 MB.

If the encoded text is wrapped into lines — common in email — each line break adds one or two more characters, raising the overhead by roughly another 4% in typical MIME output. This is the unavoidable cost of representing 256 possible byte values using only 64 printable ones: you simply need more symbols to say the same thing. It is also why Base64 is a poor choice when bandwidth or storage is tight and the channel can already carry binary directly.

Base64 vs Base64URL vs Base32 vs hex

Standard Base64 uses + and /, but both characters are awkward in some contexts: / is a path separator and + often means a space in URLs and form data. RFC 4648 §5 defines a "URL and filename safe" variant, usually called Base64URL, that swaps those two characters — - (minus) replaces + at position 62, and _ (underscore) replaces / at position 63. The padding = is frequently omitted as well, since it too can need escaping. Base64URL is what you see inside JSON Web Tokens (JWT), in URL query parameters, and in filenames.

The same RFC also defines two siblings that trade density for a smaller, sometimes safer alphabet:

Use hex when you want something human-readable and trivially aligned to bytes (each byte is exactly two hex digits). Use Base32 when the text must survive case-insensitive systems or be read aloud or typed by hand. Use Base64 or Base64URL when density matters most — the common case on the web.

Line-length conventions: 76 and 64

Older text channels disliked very long lines, so two line-length conventions became standard. MIME (RFC 2045) limits Base64 to 76 characters per line, while PEM (RFC 1421) uses exactly 64 characters per line — the wrapping you still see in TLS certificates and SSH keys printed between -----BEGIN----- and -----END----- markers. The shorter lines kept messages within the limits of early mail software and terminals.

Crucially, line wrapping is a property of the surrounding format, not of Base64 itself. RFC 4648 is explicit that implementations "MUST NOT add line feeds to base-encoded data unless the specification referring to this document explicitly directs" them to. A bare Base64 string — the kind this tool produces — is therefore a single unbroken line. When you decode text copied from an email or certificate, any embedded newlines and spaces must be stripped first; this tool does that automatically.

What Base64 is used for

Once you can turn any bytes into safe text, the uses multiply. The most common are:

• Email attachments (MIME). Every image, PDF, or document attached to an email is Base64-encoded in transit — the original purpose that drove the format into ubiquity.
• data: URIs. A whole file can be embedded inline as data:[mediatype];base64,<data>, letting a page carry a small icon, font, or image with no extra HTTP request. The trade-offs are the 33% size penalty and the loss of separate caching: an embedded asset cannot be cached or reused independently of the document that contains it, so this is best reserved for tiny, rarely-changing files.
• Embedding assets in CSS and HTML. The same data: trick inlines background images, SVGs, and web fonts directly inside stylesheets.
• Binary inside JSON and XML. Neither format can hold raw bytes, so binary fields — file uploads, thumbnails, cryptographic keys — are carried as Base64 strings.
• HTTP Basic authentication. The Authorization: Basic header carries the Base64 of username:password. For example Aladdin:open sesame becomes QWxhZGRpbjpvcGVuIHNlc2FtZQ== (defined in RFC 7617).
• JSON Web Tokens. A JWT's header, payload, and signature are each Base64URL-encoded and joined with dots, producing a compact, URL-safe token.

Base64 is not encryption — a common myth

This is the single most important thing to understand. Base64 provides no security whatsoever. It is a public, reversible mapping with no key — anyone can decode any Base64 string instantly, exactly as this page does. It does not hide, scramble, or protect data; it only changes the representation of bytes that are already known.

Two everyday examples prove the point. HTTP Basic authentication sends your password as Base64, which is why RFC 7617 stresses it "does not provide confidentiality" and must always run over HTTPS/TLS — the Base64 is trivially decoded by anyone watching the connection. Similarly, the claims in a signed JWT are Base64URL-encoded, not encrypted: paste the middle segment into any decoder and you can read every field. A JWT signature proves the token has not been tampered with, but it does nothing to keep the contents secret.

And unlike compression, Base64 makes data larger, not smaller. If you need confidentiality, encrypt the data (you may then Base64 the ciphertext for transport). If you need a smaller payload, compress it. Base64 is purely about safe transport through text-only channels — nothing more.

Common mistakes when encoding and decoding

• Forgetting UTF-8 for non-ASCII text. In the browser, the classic btoa() function works byte-by-byte and throws on any character whose code point exceeds 0xFF — so an emoji or an accented letter breaks naive code. The fix is to convert the string to its UTF-8 bytes first, then Base64 those bytes. This tool does exactly that, so accents, non-Latin scripts, and emoji round-trip correctly.
• Whitespace and newlines when decoding. Base64 copied from emails, certificates, or config files often contains line breaks and spaces, and many decoders reject them. Strip all whitespace before decoding (this tool removes it automatically).
• Missing or wrong padding. Some sources drop the trailing = characters, especially Base64URL. Strict decoders may then fail, while lenient ones re-add the padding implied by the string's length. If a decode fails, check that the character count is a multiple of four.
• Confusing the two alphabets. Feeding Base64URL (- and _) into a standard Base64 decoder — or the reverse — corrupts the result. Convert - to + and _ to / (or vice versa) before decoding.
• Treating it as security. As above, never use Base64 to "hide" a secret. It is encoding, not encryption.

Frequently asked questions

Is my data uploaded anywhere?

No. Encoding and decoding happen entirely in your browser using JavaScript. Your text never leaves your device.

Does this support Unicode and emoji?

Yes. The tool encodes text as UTF-8 first, so accented characters, non-Latin scripts, and emoji all encode and decode correctly.

What is Base64 used for?

Base64 represents binary data as ASCII text so it can travel safely through systems built for text — email (MIME), JSON, XML, data URIs, and HTTP headers.