About

Base64 encoding maps arbitrary binary data onto a 64-character ASCII subset (A - Z, a - z, 0 - 9, +, /) defined in RFC 4648. Every group of 3 input bytes (24 bits) produces 4 Base64 characters; when the input length is not divisible by 3, the output is padded with = symbols. A common mistake is feeding multi-byte UTF-8 text into the native btoa function, which throws a DOMException for any codepoint above 127. This tool handles both pure ASCII and full UTF-8 input by first encoding the string into a byte stream via TextEncoder, then performing the 6-bit chunking manually. Mishandling this step corrupts data silently in data URIs, email MIME attachments, and JWT payloads.

This converter operates entirely client-side. No data leaves your browser. It approximates instant conversion for inputs up to several megabytes. Note: the output size is always approximately 133% of the input due to the 3 - to - 4 byte expansion ratio. Pro tip: if you are encoding binary files, use a file-to-Base64 tool instead, as pasting raw binary into a text field causes data loss at null bytes.

Formulas

The Base64 encoding algorithm processes the input byte stream in groups of 3 octets. Each group of 24 bits is split into four 6-bit indices, each mapped to a character in the Base64 alphabet.

n_out = 4 × ⌈ n_in3 ⌉

where n_in is the byte length of the input and n_out is the character count of the Base64 output including padding.

For each triplet of bytes b₀, b₁, b₂, the four indices are extracted via bitwise operations:

i₀ = b₀ >> 2

i₁ = (b₀ & 3) << 4 | b₁ >> 4

i₂ = (b₁ & 15) << 2 | b₂ >> 6

i₃ = b₂ & 63

Each index i ∈ [0, 63] maps to alphabet[i] where the alphabet is the string ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/. When fewer than 3 bytes remain, missing bytes are treated as 0 and the corresponding output positions are replaced with =.

For UTF-8 input, the string is first encoded via TextEncoder into a Uint8Array, then the same algorithm is applied to the resulting byte sequence. This ensures codepoints above 127 (multi-byte sequences) are correctly represented.

Reference Data

ASCII Character	Decimal	Binary (8-bit)	Base64 Index	Base64 Char
A	65	01000001	0	A
B	66	01000010	1	B
Z	90	01011010	25	Z
a	97	01100001	26	a
z	122	01111010	51	z
0	48	00110000	52	0
9	57	00111001	61	9
+	43	00101011	62	+
/	47	00101111	63	/
= (pad)	61	00111101	-	=
Space	32	00100000	-	-
Newline (LF)	10	00001010	-	-
Tab (HT)	9	00001001	-	-
!	33	00100001	-	-
@	64	01000000	-	-
#	35	00100011	-	-
Input: 1 byte	Remainder 1		Output: 2 chars + ==
Input: 2 bytes	Remainder 2		Output: 3 chars + =
Input: 3 bytes	Remainder 0		Output: 4 chars (no pad)
Input: n bytes	General		Output: 4 × ⌈n ÷ 3⌉ chars

Frequently Asked Questions

The native btoa() function in browsers expects a binary string where every character has a codepoint in the range 0-255 (Latin-1). Characters outside this range - including emoji, CJK characters, and many accented letters encoded in multi-byte UTF-8 - trigger a DOMException. The correct approach is to first encode the string to a Uint8Array via TextEncoder, convert each byte to a Latin-1 character with String.fromCharCode(), and then pass that binary string to btoa(). This tool performs that step automatically when it detects non-ASCII input.

Base64 expands data by a factor of exactly 4/3, since every 3 input bytes produce 4 output characters. Including padding, the output length is 4 × ⌈n/3⌉ characters. For example, a 300-byte input produces exactly 400 Base64 characters. In practice, some implementations insert line breaks every 76 characters (per MIME RFC 2045), which adds further overhead. This tool does not insert line breaks, producing raw Base64.

No. Base64 is a reversible encoding scheme, not encryption. Anyone with access to the Base64 string can decode it instantly without any key. It provides zero confidentiality. Its purpose is to safely transport binary data through text-only channels (email, JSON, URLs). If you need to protect data, apply AES or another cipher before Base64-encoding the ciphertext.

Standard Base64 (RFC 4648 §4) uses + and / as characters at index 62 and 63. URL-safe Base64 (RFC 4648 §5) replaces these with - and _ respectively, because + and / have special meaning in URLs and filenames. Padding with = is often omitted in URL-safe variants. This tool uses standard Base64. To convert the output to URL-safe, replace + with -, / with _, and strip trailing = characters.

Padding ensures the Base64 output length is always a multiple of 4. If the input byte count mod 3 is 1, two = are appended. If mod 3 is 2, one = is appended. If mod 3 is 0, no padding is needed. Padding can be safely removed for storage or transmission if the decoder is aware: the decoder can infer the original length from the output length mod 4. However, many standard decoders (including atob()) expect padding and will reject unpadded input.

This tool is designed for string input. If you paste binary data into a text field, null bytes and other control characters may be stripped or corrupted by the browser's text handling. For files, use a File/Blob-based approach: read the file as an ArrayBuffer via FileReader, convert the bytes to a binary string, then encode. This tool correctly handles all printable ASCII and full UTF-8 text, but binary file encoding requires a dedicated file-input tool.