Skip to content

Encoders & Decoders

Base64 Encoder / Decoder

Encode text to Base64 or decode it back. Unicode-safe.

native (btoa/atob) Client-side
0 chars
0 chars

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
  1. Pick the direction with the Encode / Decode toggle at the top of the tool.
  2. 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.
  3. 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.
  4. 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 the Authorization header. (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.