What Is Base64 Encoding?
Base64 encoding represents binary or text data using only 64 printable ASCII characters, so it can safely pass through systems built for text (email bodies, URLs, JSON fields, HTTP headers) that would otherwise mishandle raw bytes. It is an encoding, not encryption: it provides no confidentiality, and anyone can decode it without a key. This tool works as a base64 converter in both directions: base64 encode online to turn text into Base64, or base64 decode online to turn it back, entirely in your browser. In other words, text to base64 and base64 to text conversion both happen instantly, with no upload involved.
How Base64 Encoding Works (RFC 4648)
Base64 is specified by RFC 4648, "The Base16, Base32, and Base64 Data Encodings" (2006), which obsoletes RFC 3548 (2003), itself the first RFC to formally standardize an encoding that MIME (RFC 2045, 1996) had already been using informally for email attachments. The mechanism: input bytes are grouped into 3-byte (24-bit) chunks, each chunk split into four 6-bit groups, and each 6-bit value mapped to one character in a 64-character alphabet. When the input length is not a multiple of 3 bytes, "=" padding characters fill the remainder so the output length is always a multiple of 4.
| Input bytes | Output characters | Padding |
|---|---|---|
| 3 (multiple of 3) | 4 | None |
| 1 | 2 data chars | == |
| 2 | 3 data chars | = |
Standard vs. URL-Safe (Base64url): What's the Difference?
RFC 4648 §5 defines a second alphabet specifically because the standard alphabet's "+" and "/" characters collide with meaningful characters in URLs and filenames: "+" means space in query strings, "/" is a path separator. Base64url substitutes "-" for "+" and "_" for "/", and padding is conventionally stripped since trailing "=" characters can also be misread inside a URL. This is exactly why JWTs use base64url encode for their header and payload segments rather than standard Base64. The token has to survive being placed directly in a URL or an HTTP header.
Common Base64 Errors and What They Mean
Most Base64 decode failures come down to a small set of causes, and this tool's inline highlighter flags the responsible character directly in the input rather than making you guess from a generic browser error. An "invalid character" error happens when a character outside the active alphabet appears in the input, most often a "-" or "_" pasted while Standard mode is selected (or the reverse: "+"/"/" while URL-safe is selected), or genuine corruption from a copy-paste, valid characters are always A–Z, a–z, 0–9, plus the two alphabet-specific symbols and the "=" padding character. A Base64 string whose length is not a multiple of 4 (after accounting for padding) cannot decode, extra padding somewhere other than the end, or padding that does not match the remainder math, both fail the same way, URL-safe Base64 conventionally omits padding entirely, that is expected, not an error, and this tool automatically re-derives the correct padding from the string's length before decoding, avoiding a base64 padding error on decode.
Base64 and Unicode: Why Naive btoa() Breaks on Emoji and Accents
The browser's native btoa()/atob() functions operate on a byte string, treating each character code as a single byte, valid only for code points 0–255 (the Latin-1 range). Anything above that, including emoji and most non-Latin scripts, makes a raw btoa() call throw "The string to be encoded contains characters outside of the Latin1 range." This is a historical quirk: btoa/atob predate JavaScript's UTF-16 string model, originating in the old Netscape window object. This tool avoids the error by converting the input to real UTF-8 bytes with TextEncoder first, then mapping each byte to a character code before calling btoa. This is the standard, correct fix for base64 unicode emoji handling, rather than the older btoa(unescape(encodeURIComponent(str))) hack still copy-pasted around the web. This tool encodes and decodes only, it does not encrypt, sign, or verify anything, and a successful decode only proves the input was valid Base64, not that the decoded content is meaningful or safe. It does not stream extremely large inputs either, btoa/atob run synchronously, so a very large paste (tens of MB) can briefly pause the tab, and it does not persist input anywhere, nothing is uploaded and nothing is retained after you leave the page.