About

Base64 encoding converts arbitrary binary data into a restricted set of 64 ASCII characters (A - Z, a - z, 0 - 9, +, /) plus = for padding. Every group of 3 input bytes maps to 4 output characters, producing an output size ratio of exactly 43. Encoding a raw Unicode string without first converting it to UTF-8 bytes is the single most common source of corruption in data pipelines, API payloads, and email attachments. This tool performs proper UTF-8 byte serialization before applying the Base64 alphabet, so multi-byte characters (emoji, CJK, Cyrillic) encode correctly.

Two encoding variants are supported. Standard Base64 follows RFC 4648 §4 and is used in MIME email and PEM certificates. URL-safe Base64 follows RFC 4648 §5, replacing + with - and / with _, and stripping = padding, which prevents breakage in query strings and filenames. Choosing the wrong variant will cause parse failures downstream. This tool approximates output size instantly and lets you toggle MIME line wrapping at 76 characters per RFC 2045.

Formulas

Base64 processes input as a stream of bytes. Each group of 3 bytes (24 bits) is split into 4 sextets (6 bits each). Each sextet indexes the Base64 alphabet table above.

n_out = 4 ⋅ ceil(n_bytes3)

Where n_out = number of output Base64 characters (including padding), and n_bytes = byte length of the UTF-8 encoded input. The overhead ratio converges to 43 ≈ 1.333 for large inputs.

Bit extraction for sextet k from a 24-bit group G:

index_k = (G >> (18 − 6k)) ∧ 0x3F

Where k ∈ {0, 1, 2, 3} and 0x3F = 63 masks the lower 6 bits.

For URL-safe encoding (RFC 4648 §5), two substitutions are applied to the output alphabet:

+ → - , / → _ , = padding removed

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 character: = - appended when input byte length is not divisible by 3

Frequently Asked Questions

The native btoa() function only accepts Latin-1 (ISO 8859-1) characters, where each code point fits in a single byte (range 0 - 255). Characters outside this range (emoji, CJK, Cyrillic, Arabic) have code points above 255 and cause an InvalidCharacterError. The correct approach is to first encode the string to UTF-8 bytes using TextEncoder, then Base64-encode those bytes. This tool performs that conversion automatically.

Standard Base64 uses + and /, which are reserved characters in URLs (RFC 3986). If you embed a Base64 value in a query parameter, path segment, or filename, those characters will be percent-encoded or misinterpreted by parsers. URL-safe Base64 (RFC 4648 §5) replaces + with - and / with _, and omits = padding. Use it for JWT tokens, URL parameters, cookie values, and any context where the string passes through a URL parser.

RFC 2045 (MIME) mandates that Base64-encoded content in email bodies must not exceed 76 characters per line, with lines terminated by CRLF. This prevents mail transfer agents from truncating or corrupting long lines. If you are generating Base64 for HTTP headers, JSON payloads, or data URIs, do not use line wrapping. Only enable it for MIME email bodies or PEM certificate files.

Base64 output is always exactly 43 the size of the input byte stream, rounded up to the nearest multiple of 4 (due to padding). For a 1000-byte input, the output is 1336 characters. If MIME line wrapping is enabled, additional CRLF sequences add roughly 2.6% overhead.

No. Base64 is an encoding scheme, not encryption. It is trivially reversible by anyone with a decoder. It provides zero confidentiality. Do not use Base64 to hide passwords, API keys, or sensitive data. If you need security, apply actual encryption (AES-256, RSA) before Base64-encoding the ciphertext for transport.

JavaScript strings are limited to approximately 2²⁸ characters in V8 (Chrome, Edge) and 2³⁰ in SpiderMonkey (Firefox). For inputs exceeding a few hundred megabytes, the browser tab will run out of memory. For typical use cases (configuration files, API payloads, short messages), the encoding completes in under 1 millisecond. The tool displays byte size and character count so you can monitor input scale.