About

Base64 encodes binary data into a 64-character ASCII subset defined by RFC 4648. The native btoa() function in browsers only handles Latin-1 codepoints (U+0000 to U+00FF). Feed it a multibyte UTF-8 character and it throws. This tool bridges that gap by routing input through encodeURIComponent before encoding, preserving full Unicode. A 1 KB plaintext input expands to roughly 1.37 KB in Base64 due to the 43 ratio. Misapplied encoding corrupts data silently in APIs, email attachments (MIME mandates 76-character lines), and data URIs. This tool validates input, reports byte sizes, and supports URL-safe variants where + and / are replaced with - and _.

Formulas

Base64 maps every group of 3 input bytes (24 bits) to 4 ASCII characters (6 bits each). The output length formula:

L_out = 4 ⋅ ceil(L_in3)

Where L_in = input byte length, L_out = output character count. The size overhead ratio is exactly 43 ≈ 1.333. With MIME line breaks every 76 characters (RFC 2045), CRLF pairs add further overhead.

For UTF-8 safe encoding in browsers, the pipeline is:

btoa(unescape(encodeURIComponent(str)))

encodeURIComponent converts each multibyte codepoint into percent-encoded octets. unescape interprets those octets as raw Latin-1 bytes. btoa then safely encodes the Latin-1 string. Decoding reverses the chain: decodeURIComponent(escape(atob(b64))).

URL-safe Base64 substitutes index 62 (+ → -) and index 63 (/ → _), then strips trailing = padding.

Reference Data

Character	Index	Character	Index	Character	Index	Character	Index
A	0	Q	16	g	32	w	48
B	1	R	17	h	33	x	49
C	2	S	18	i	34	y	50
D	3	T	19	j	35	z	51
E	4	U	20	k	36	0	52
F	5	V	21	l	37	1	53
G	6	W	22	m	38	2	54
H	7	X	23	n	39	3	55
I	8	Y	24	o	40	4	56
J	9	Z	25	p	41	5	57
K	10	a	26	q	42	6	58
L	11	b	27	r	43	7	59
M	12	c	28	s	44	8	60
N	13	d	29	t	45	9	61
O	14	e	30	u	46	+	62
P	15	f	31	v	47	/	63
Padding		= (appended when input byte count mod 3 ≠ 0)

Frequently Asked Questions

The native btoa() function only accepts characters in the Latin-1 range (U+0000 to U+00FF). Any character outside this range - including emoji, CJK, Cyrillic, or Arabic - causes the error. This tool solves it by first converting the input to UTF-8 percent-encoded octets via encodeURIComponent(), then reinterpreting those octets as Latin-1 bytes via unescape() before calling btoa(). The decode path reverses this precisely.

Base64 produces 4 output characters for every 3 input bytes, yielding a fixed 33.33% size increase. For an input of L bytes, the output is 4 × ceil(L/3) characters. If MIME line wrapping is enabled (76 characters per line + CRLF), the overhead increases further by approximately 2.6% due to the inserted line breaks.

Standard Base64 uses "+" and "/" which are reserved characters in URLs and filenames. URL-safe Base64 (RFC 4648 §5) replaces "+" with "-" and "/" with "_", and typically omits padding "=" characters. Use it for JWT tokens, URL query parameters, filename-safe identifiers, and any context where the encoded string travels through URL parsers or filesystem APIs.

Yes. The file input reads the file as a data URI via FileReader.readAsDataURL(), which produces a full Base64 data URI including the MIME type prefix (e.g., 'data:image/png;base64,...'). You can also extract the raw Base64 portion without the prefix. Files up to 5 MB are supported; larger files risk browser memory constraints.

Padding ensures the 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. Many decoders (including this tool and most modern parsers) can infer the missing bytes without padding, so stripping it is safe in controlled environments. However, strict RFC 4648 §3.2 decoders will reject unpadded input.

No. Base64 is a reversible encoding scheme with no key, no secret, and no security. Any observer can decode the output instantly. It exists solely to represent binary data in text-safe formats (email, JSON, XML, URLs). For confidentiality, apply actual encryption (AES, ChaCha20) before Base64-encoding the ciphertext for transport.