Base64 decode and encode
Decode Base64 back to text, or encode text to Base64 — UTF-8 safe and 100% in your browser.
Runs 100% in your browserHow to encode or decode Base64
- Choose a mode. Pick Encode to convert text to Base64, or Decode to convert it back.
- Enter your text. Type or paste into the input box; the result appears instantly.
- Copy the result. Click Copy to grab the output.
How Base64 actually works
Computers store everything as bytes, but many systems — JSON, XML, email headers, URLs, source code —
can only carry a safe subset of printable text. Base64 bridges that gap. It takes arbitrary binary data
and re-expresses it using just 64 characters that survive any text channel: A–Z,
a–z, 0–9, + and /. The mechanism is pure arithmetic:
take three bytes (24 bits), slice them into four 6-bit chunks, and map each chunk (a value from 0 to 63)
to one of those 64 characters. Three bytes in, four characters out — which is why Base64 output is always
about a third larger than the original. There is no compression and no lookup table to memorise; it is a
deterministic, reversible re-packing of bits.
Where you meet Base64 every day
It is one of the most quietly ubiquitous formats on the web. Data URLs
(data:image/png;base64,…) inline a small image or font directly into HTML or CSS so it
loads without a separate request. JSON Web Tokens Base64URL-encode their header and
payload. HTTP Basic Auth sends user:password as a single Base64 string.
Email attachments have been Base64-encoded since the MIME standard, because old mail
servers only handled 7-bit text. API keys, certificates and PEM files wrap binary key
material in Base64 so it can be pasted into a config file. In every case the job is the same: move binary
through a text-only pipe.
Padding and the URL-safe variant
The = characters you sometimes see at the end are padding. Because Base64 works in
three-byte groups, the encoder pads the final group out to four characters with = so the
decoder knows how many real bytes it held — one = means the last group was two bytes, two
means one byte. There is also a URL-safe variant that swaps + and
/ for - and _ (and usually drops the padding) so the value can ride
inside a URL or filename without being percent-escaped. That is the form JWTs use. If you need to make a
Base64 value URL-safe in the other direction, percent-encoding is the job of the
URL encoder.
Why a decode fails — and why it isn't security
When a decode produces garbage or an error, the cause is almost always one of a few things: stray
whitespace or line breaks from a wrapped email body, a missing or mismatched padding count, or feeding
URL-safe text (-/_) through a standard decoder. This tool tolerates the common
cases, but Base64 has no checksum — a string that was never valid Base64 will simply round-trip to
gibberish, because the format cannot tell that the input was wrong. And to be unambiguous:
Base64 is not encryption. It uses no key and hides nothing; anyone can reverse it
instantly. If you need confidentiality, encrypt the data and then Base64 the ciphertext only if you need
it text-safe. To convert between Base64 and other low-level representations, the
hex converter
handles the base-16 side. Writing your own? Our guide to
Base64 in JavaScript
walks through the UTF-8-safe encode/decode (and why btoa breaks on emoji) with copy-paste code.
Frequently asked questions
- Base64 represents binary data using 64 printable ASCII characters (A–Z, a–z, 0–9, + and /). It is used to embed binary data — like images or keys — in text-only formats such as JSON, email or data URLs.
- Paste your Base64 string and switch to Decode — it is converted back to the original text instantly in your browser. UTF-8 text, including accented characters and emoji, round-trips correctly.
- No. Base64 is encoding, not encryption — it provides no security. Anyone can decode it instantly, with no key. It only makes data text-safe; it does not hide it. Never use it to protect secrets — encrypt the data first, then Base64 the ciphertext if you need it text-safe.
- Because it encodes every 3 bytes (24 bits) as 4 ASCII characters (each carrying 6 bits of data), output is always about 33% larger than the input. That overhead is the price of being text-safe. It is why you embed small assets like icons as data URLs but stream large files as raw binary — and why Base64 is a transport format, not a storage-efficiency one.
- The = characters are padding. Base64 processes input in 3-byte groups; when the last group is short by one or two bytes, the encoder pads the output to a multiple of four characters with = so a decoder knows exactly how many real bytes the final group held. One = means the last group was 2 bytes, two = means it was 1 byte, and no = means it divided evenly.
- Standard Base64 uses + and /, which have special meaning in URLs and filenames. URL-safe Base64 (RFC 4648 §5) swaps them for - and _ and usually drops the = padding, so the value can travel in a query string, path or filename without being re-escaped. JSON Web Tokens use this variant. Feeding URL-safe text to a strict decoder is a common cause of decode failures; this tool accepts both the standard and URL-safe alphabets, so either pastes cleanly.
- Yes. Text is encoded as UTF-8 before Base64, so accented characters, emoji and other non-ASCII text round-trip correctly. (Naive btoa() alone throws on non-Latin1 characters; this tool encodes to UTF-8 bytes first, which is the correct approach.)
- No. Encoding and decoding happen entirely in your browser with the built-in btoa/atob primitives — your input is never uploaded, logged or stored. As a general habit, still treat production secrets carefully in any browser tool, but the data itself never leaves this tab.