Encoders & Decoders
Base64 Encoder / Decoder
Encode text to Base64 or decode it back. Unicode-safe.
Unicode-safe: full UTF-8 support including emoji, CJK, and right-to-left scripts. All conversion happens locally in your browser.
Frequently Asked Questions & Guide
How to use this Base64 Encoder / Decoder
- Pick the direction with the Encode / Decode toggle at the top of the tool.
- Type or paste your text (when encoding) or your Base64 string (when decoding) into the left-hand panel. Conversion happens live as you type — no button to click.
-
If your target transport is a URL path or query string, tick the
URL-safe variant checkbox. This replaces
+with-and/with_, and strips the trailing=padding — the variant defined in RFC 4648 §5 and used in JWTs, Data URLs, and OAuth 2.0 PKCE challenges. - Use Swap to feed the output back as the input — handy when you want to round-trip a string. Use Copy to grab the result for use elsewhere.
What is Base64?
Base64 is a binary-to-text encoding scheme that represents binary data
in an ASCII string format by translating it into a radix-64
representation. It is defined in
RFC 4648
and is one of the most widely used encodings on the web. Every three
bytes of input become four ASCII characters from the alphabet
A–Z, a–z, 0–9, +, /,
with = used for padding at the end of the string.
Base64 is not encryption. It provides no confidentiality — anyone can decode a Base64 string by definition. Its purpose is to make binary data safe to transmit through channels that are designed to handle text: JSON fields, HTTP headers, email bodies, XML documents, URL query parameters, and Data URLs. Common real-world uses include:
- Embedded images in HTML/CSS — small icons and
sprites are often inlined as
data:image/png;base64,...to save an HTTP roundtrip. - HTTP Basic Authentication — credentials are encoded
as
Basic base64(user:pass)in theAuthorizationheader. (Always pair with HTTPS — Base64 is trivially reversible.) - JWTs — every JSON Web Token is three base64url-encoded JSON objects joined by dots.
- Email attachments (MIME) — binary attachments are Base64-encoded so they can travel through 7-bit ASCII mail servers.
- Data URLs and source maps — both rely on Base64 to inline binary payloads inside text-based formats.
Why do non-ASCII characters break with naive btoa()?
The native btoa() function only accepts strings whose
characters all fit in a single byte (Latin-1, code points 0–255). Pass
it a Chinese character, an emoji, or any character above U+00FF and it
throws InvalidCharacterError. This tool works around the
limitation by first encoding the string to UTF-8 bytes via
TextEncoder, then converting those bytes back into a
Latin-1 string, and finally calling btoa(). The decoding
path mirrors this exactly. The result is a Base64 encoder that handles
any Unicode text correctly — including emoji, CJK, RTL scripts, and
mathematical symbols.
What is the URL-safe variant?
Standard Base64 uses + and /, both of which
have special meaning in URLs and would need to be percent-encoded.
RFC 4648 §5 defines an alternate alphabet that replaces them with
- and _, and which typically omits the
trailing = padding. This variant is used by JWTs, by OAuth
2.0 PKCE code challenges, and by many database engines for ID
generation. Toggle the URL-safe variant checkbox to
produce or consume this format.
Is my data sent to a server?
No. This tool uses only native browser APIs (btoa,
atob, TextEncoder, decodeURIComponent).
There is no network request of any kind — your input never leaves your
device.
Why does Base64 make my data bigger?
Because each group of 3 input bytes becomes 4 output characters, Base64 always inflates data by roughly 33%. A 1 MB file becomes a ~1.33 MB Base64 string. This is a deliberate trade-off: the size increase buys you a string that can safely pass through any text-only channel.