How Base64 Encoding Works
Base64 converts binary data into a text-safe format using 64 printable ASCII characters (A–Z, a–z, 0–9, +, /). Every 3 bytes of input become exactly 4 Base64 characters — hence the ~33% size increase. Padding with = signs ensures the output length is always a multiple of 4.
This tool encodes text as UTF-8 bytes first (using the browser's TextEncoder API), then Base64-encodes those bytes. This means it correctly handles accented characters, emoji, Chinese characters, and any other Unicode text — not just ASCII. The URL-safe variant replaces + with -, / with _, and strips the = padding, making the output safe to include in URLs without further encoding.
References
Base64 encoding is formally defined in RFC 4648 — The Base16, Base32, and Base64 Data Encodings (S. Josefsson, October 2006, rfc-editor.org/rfc/rfc4648). Section 4 defines standard Base64, and Section 5 defines the URL-safe alphabet (- and _ replacing + and /). This tool implements both alphabets.
What's here — and what's not
Two-way conversion, URL-safe toggle, UTF-8 correctness (not just ASCII), inline copy buttons for both panes, and a swap button that flips direction and moves the output into the input. The info callout reminds you of the 33% size overhead — useful when deciding whether Base64 is appropriate for your use case.
What isn't here: binary file encoding (drag-and-drop a .jpg and get Base64) is not in v1 — that requires FileReader API work and preview rendering. Also absent: Base32, Base16/hex encoding, or streaming for large inputs. Those add enough scope to belong in separate tools.