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.
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 use the Base64 encoder
- Make sure Encode mode is selected (the default for this tool).
- Type or paste your text into the Plain Text input — emoji and accented characters are fine.
- Read the Base64 Result as it updates live; no button press is needed.
- Press Copy to send the encoded string to your clipboard.
- 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.
| Input | Bytes | Base64 output | Padding |
|---|---|---|---|
| Man | 3 | TWFu | none |
| Ma | 2 | TWE= | = |
| M | 1 | TQ== | == |
| hello | 5 | aGVsbG8= | = |
| 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.
Related encoding & crypto tools
Reverse a Base64 string back to text
Base64 to ImagePreview a Base64 data URI as an image
Image to Base64Encode an image into a data URI
URL EncoderPercent-encode a string for safe URLs
URL ParserBreak a URL into its components
JWT DecoderDecode Base64url-encoded JWT claims
HMAC GeneratorSign data with a keyed HMAC hash
Hash GeneratorMD5, SHA-1, SHA-256 fingerprints
JSON FormatterFormat the JSON you embed Base64 into
All ToolsBrowse the full Toolk hub
Guide: Base64 EncodingHow Base64 works, end to end
Guide: JWT StructureWhy JWTs are Base64url, not encrypted
Last updated: August 23, 2026 · Runs 100% in your browser — no uploads, nothing leaves your device.
Frequently asked questions
Does this encoder handle emoji and non-Latin scripts?
Yes. Text is UTF-8 encoded before Base64, so 🚀 becomes 8J+agA== and café becomes Y2Fmw6k= instead of crashing. Raw btoa() throws InvalidCharacterError on anything above U+00FF — this tool encodes the bytes first, which sidesteps that limit.
Is Base64 encoding the same as encryption?
No. Base64 is a reversible transport encoding with no key, so it provides zero confidentiality — anyone can decode it in one step. Hash or properly encrypt secrets instead; never rely on Base64 to hide them.
Why is the encoded output about 33% larger than my text?
Base64 maps every 3 input bytes onto 4 printable characters, and that fixed 4:3 ratio adds roughly one third of overhead. Trailing = signs pad the final group so the output length lands on a multiple of 4.
Is my text uploaded anywhere while encoding?
No. Encoding is processed locally in your browser via btoa() after a UTF-8 pre-pass, and Toolk's page analytics do not receive the text you paste. Nothing leaves your device, and the page keeps working offline once loaded.
How do I turn a Base64 string back into the original text?
Paste the result into the Base64 Decoder at /tools/base64-decoder — it reverses exactly what this encoder produces, including emoji and accented round-trips, because both sides share the same UTF-8 handling.
Need a different tool?
Browse all 99 browser-based tools (99 currently marked free), or tell us what useful utility we should build next.