Ad Space

Input Text

Output

Ad Space

What Is Base64, and What Is It For

Base64 is a way of representing arbitrary binary data — or any text — using only 64 printable ASCII characters (A-Z, a-z, 0-9, plus + and /), with = used as padding at the end. It exists because many older systems and text-only formats (email, JSON, XML, CSS) were never designed to carry raw binary bytes safely — a binary byte could accidentally be interpreted as a control character or break the format's structure. Base64 sidesteps that entirely by re-encoding the data as plain text first. Common real-world uses include email attachments (MIME), embedding a small image directly inside a CSS or HTML file as a data URI instead of a separate file request, and storing binary values like encryption keys or file contents inside a JSON or XML field.

Worked Example

The text "Hello, World!" encodes to "SGVsbG8sIFdvcmxkIQ==". Notice the trailing == padding — Base64 processes input three bytes at a time, converting each group of three bytes into four output characters; when the input length isn't a multiple of three, = characters pad the last group so the output length still comes out even. Decoding "SGVsbG8sIFdvcmxkIQ==" reverses the process exactly, returning "Hello, World!".

The UTF-8 Pitfall Most Simple Base64 Tools Get Wrong

JavaScript's built-in btoa() and atob() functions only understand Latin1 — one byte per character, values 0 to 255. That's fine for plain English text, but the moment you try to encode an emoji, an accented letter like é, or most non-Latin scripts, plain btoa() either throws a character-out-of-range error or silently produces garbage, because those characters don't map to a single Latin1 byte at all. Many simple online Base64 tools never account for this and quietly break on anything beyond basic ASCII.

This tool avoids that entirely by converting text to its proper UTF-8 byte sequence first, using the browser's built-in TextEncoder, before handing those bytes to btoa — and reversing the same two steps in order on decode, using TextDecoder. A string like "héllo 🎉" is first turned into its correct multi-byte UTF-8 representation, which only ever contains values in the safe 0-255 range that btoa can handle correctly, and decoding reconstructs the exact original text, emoji included — something plain btoa/atob cannot do reliably on its own.

A Brief History of Base64

Base64 belongs to a family of binary-to-text encoding schemes that predate it — uuencode, developed in the late 1970s for transferring files between Unix systems, and BinHex, used on early Macintosh systems, both solved the same basic problem of moving binary files through text-only channels, just with different character sets and framing rules.

The specific Base64 scheme in use today was standardized as part of MIME (Multipurpose Internet Mail Extensions), the specification that added support for attachments, non-text content, and non-ASCII characters to email, which had originally been designed to carry only plain 7-bit ASCII text. MIME was defined in RFC 1521 in 1993 by Nathaniel Borenstein and Ned Freed, and Base64 quickly spread well beyond email — into data URIs, XML and JSON payloads, and countless other places where binary data needs to survive being treated as plain text.

Common Base64 Mistakes

Assuming Base64 provides any security or privacy is the most consequential mistake — it is purely an encoding, reversible by anyone with no key needed, and should never stand in for real encryption. Feeding non-ASCII text into a naive btoa()-only tool is the second, covered in detail above. A third is expecting decoded output to always be readable text — Base64 is just as often used to represent binary data (an image, a file, encryption bytes) that won't display as sensible characters once decoded, which is expected behavior, not a bug.

Base64 Terms You Should Know

Padding — the trailing = or == characters that fill out the final group of output characters when the input length isn't a multiple of three bytes.

Data URI — a way of embedding a file's Base64-encoded content directly inside an HTML or CSS attribute (e.g. an image), avoiding a separate network request.

MIME — the email standard that popularized Base64 for safely attaching binary files to text-based email messages.

UTF-8 — the character encoding that represents text (including emoji and non-Latin scripts) as a sequence of bytes; this tool converts to UTF-8 bytes before Base64-encoding so non-ASCII text round-trips correctly.

Frequently Asked Questions

What is Base64 encoding used for?

Base64 turns arbitrary binary or text data into a string of plain ASCII characters, so it can be safely embedded somewhere that only accepts text — an email attachment, a data URI inside CSS or HTML, or a binary value stored inside a JSON or XML field.

Why does plain btoa() break on emoji or accented characters?

btoa() only understands Latin1, one byte per character. Any character outside that range — an emoji, an accented letter, most non-Latin scripts — either throws an error or gets silently mangled. This tool converts text to UTF-8 bytes first with TextEncoder, so btoa only ever sees valid Latin1-range values.

Is Base64-encoded text encrypted or secure?

No. Base64 is an encoding, not encryption — anyone can decode it back to the original text instantly, with no key or password required. It should never be used to protect sensitive data.

What happens if I try to decode invalid Base64?

This tool shows a clear "Invalid Base64 input" message instead of crashing. Valid Base64 only contains letters, digits, +, /, and = padding at the end — anything else, or an incorrect length, will trigger this message.

Ad Space