Skip to main content

Base64 Encoder Online — Free UTF-8 & Emoji-Safe

Encode text to a Base64 string instantly. Handles UTF-8, emoji, and CJK characters that raw btoa() rejects. Free and 100% in your browser — nothing is uploaded.

0 characters
0 characters
Security: 100% Client-Side UTF-8 Engine
Compliance: RFC 4648 Technical Standard

Why Use Our Base64 Encoder?

Instant Encoding

Convert your text to Base64 in real-time as you type, with zero latency.

Unicode Support

Full support for UTF-8 characters, emojis, and special international symbols.

100% Secure

Everything runs locally in your browser. Your sensitive text never leaves your device.

Base64 Encoder: Convert Text to a Base64 String Online

A Base64 encoder turns text or binary data into an ASCII string built from 64 safe characters, so it survives transport over text-only channels like email, JSON, and URLs. Paste any text — including emoji and CJK — and this tool returns the Base64 result instantly, following RFC 4648. It runs 100% in your browser, free, with no upload. To reverse it, use the Base64 Decoder.

How to encode text to Base64

  1. Make sure Encode mode is selected (the default for this tool).
  2. Type or paste your text into the Plain Text input — emoji and accented characters are fine.
  3. Read the Base64 Result as it updates live; no button press is needed.
  4. Press Copy to send the encoded string to your clipboard.
  5. To recover the original, paste the result into the Base64 Decoder.

What is Base64 and how does it work?

Base64 is a binary-to-text encoding that maps every 3 bytes (24 bits) of input onto 4 printable characters (4 × 6 bits). It exists because many channels — SMTP email, HTTP headers, JSON, XML, URLs — were designed for text and mangle or strip raw binary bytes. Encoding to a restricted 64-character alphabet makes the data binary-safe in transit. The scheme is standardized in RFC 4648.

The standard alphabet is A–Z, a–z, 0–9, plus + (index 62) and / (index 63). The = character is padding, added so the output length is a multiple of 4. Because 4 output characters carry 3 input bytes, the result is about 33% larger than the source. RFC 4648 §5 also defines a URL-safe variant that swaps +- and /_ so the string is safe in URLs (RFC 3986) and filenames.

"Base 64 is used in a number of situations to store or transfer data in environments that, perhaps for legacy reasons, are restricted to US-ASCII data."— RFC 4648 §4, The Base16, Base32, and Base64 Data Encodings

Worked examples: input → Base64

3 bytes · no padding

Man → TWFu

2 bytes · one = pad

Ma → TWE=

1 byte · two == pad

M → TQ==

Edge case · the btoa() Unicode trap

Calling raw btoa("🚀") in a browser throws InvalidCharacterError because the rocket emoji falls outside the Latin1 range (U+0000–U+00FF). This tool first UTF-8 encodes the bytes, so 🚀 correctly becomes 8J+agA== and café becomes Y2Fmw6k=.

Base64 reference values

Common inputs and their exact Base64 output, plus how padding tracks the input-length remainder. These are the real strings this encoder produces.

InputBytesBase64 outputPadding
Man3TWFunone
Ma2TWE==
M1TQ====
hello5aGVsbG8==
café5 (UTF-8)Y2Fmw6k==
🚀4 (UTF-8)8J+agA====

The btoa() workaround this tool actually uses

Under the hood the encoder runs btoa(unescape(encodeURIComponent(text))). JavaScript stores strings as UTF-16, but btoa() only accepts single-byte Latin1 characters, so it throws on anything above U+00FF. The encodeURIComponent step rewrites the text as UTF-8 byte sequences first, which is why emoji and multi-byte scripts encode cleanly here while a naive btoa() call crashes.

One nuance worth knowing: café (with é = U+00E9) is inside Latin1, so raw btoa("café") does not throw — but it encodes the wrong bytes (Y2Fm6Q==) instead of the correct UTF-8 result (Y2Fmw6k=). Encoding the bytes first is what keeps round-trips accurate, which is exactly what the matching Base64 Decoder relies on.

Base64 is encoding, not encryption

Base64 provides zero confidentiality. Anyone can decode it instantly with no key, so it is not a security measure — only a transport format. If you need a one-way fingerprint, use a hash generator; for keyed integrity, use an HMAC generator (RFC 2104). A common point of confusion: a JWT (RFC 7519) looks encrypted but is just URL-safe Base64 of a JSON header and payload — decoding it with the JWT Decoder reveals the claims but does not verify the signature.

Runs 100% in your browser

Your text never leaves your device. Encoding happens locally in JavaScript and the result is copied with your browser's native clipboard — no uploads, nothing leaves your device. I tested this encoder on plain ASCII (Man, hello), Latin1 accents (café), a CJK string, and the rocket emoji (🚀); every case round-trips cleanly through the Base64 Decoder back to the original text.

Frequently asked questions

Is this Base64 encoder free?

Yes — 100% free with no signup and no usage cap. Encoding runs in your browser, so the output is yours to use in any personal or commercial project.

Does it support emoji and UTF-8?

Yes. The input is UTF-8 encoded before Base64, so emoji, accents, and CJK text all encode correctly. The emoji 🚀 becomes 8J+agA== instead of throwing an error.

Is Base64 the same as encryption?

No. Base64 is a reversible encoding with no key, so it offers no security. Hash or encrypt secrets — never rely on Base64 to hide them.

Why is the output 33% bigger?

Base64 maps every 3 input bytes to 4 ASCII characters, a 4:3 ratio that adds roughly 33% overhead, with = padding aligning the final group.

Last updated: June 2, 2026 · Runs 100% in your browser — no uploads, nothing leaves your device.

Need a different tool?

Browse all 89 free, in-browser tools — or tell us what we should build next.

Browse all tools