How to encode text to Base64
- Paste the text you want to encode into the input box. Multi-line text and mixed scripts are fine; nothing is trimmed or reordered.
- Press Encode to Base64. The tool converts the text to its UTF-8 bytes and then to the standard Base64 alphabet, so non-Latin characters are handled correctly.
- Copy the result with the Copy button. It is a single unbroken string, ready to paste into a JSON field, a data URL or an authorization header.
- Need the other direction, or not sure what the output is? Use Base64 Decode for the reverse direction, or the universal converter on the home page if you are not sure what encoding a string uses.
Verified examples (9 November 2026)
Each row was produced by this encoder on 9 November 2026. The first four are the RFC 4648 §10 test vectors; the Chinese sentence is the 21-character input used for the measured example.
| Input | Output | Notes |
|---|---|---|
f | Zg== | 1 byte → 4 chars, 2 padding; RFC 4648 §10 vector |
fo | Zm8= | 2 bytes → 4 chars, 1 padding; RFC 4648 §10 vector |
foo | Zm9v | 3 bytes → 4 chars, 0 padding; RFC 4648 §10 vector |
foobar | Zm9vYmFy | 6 bytes → 8 chars, 0 padding; RFC 4648 §10 vector |
Hello | SGVsbG8= | 5 bytes → 8 chars, 1 padding; pure ASCII |
Hello 世界 | SGVsbG8g5LiW55WM | 12 bytes → 16 chars, 0 padding; each Chinese character is 3 bytes |
客户合同金额 ¥12,800 — 需要保密 | 5a6i5oi35ZCI5ZCM6YeR6aKdIMKlMTIsODAwIOKAlCDpnIDopoHkv53lr4Y= | 21 characters → 44 UTF-8 bytes → 60 chars, 0 padding |
Hugs 👋 | SHVncyDwn5GL | 9 bytes → 12 chars, 0 padding; the emoji occupies 4 bytes |
| empty string | empty output | 0 bytes → 0 chars, 0 padding |
What Base64 encoding does to your text
The alphabet has exactly 64 symbols: 26 uppercase letters (A–Z), 26 lowercase (a–z), 10 digits (0–9), plus + and /. Every group of 3 input bytes becomes 4 output characters, which is the whole reason for the size change: 4/3 = 1.333, so the output is 33.3% longer. The general formula is 4 × ceil(bytes / 3) characters, with 0, 1 or 2 = signs padding the last group.
Characters are not bytes. UTF-8 uses 1 byte for ASCII, 2 bytes for Latin-1 letters such as é, 3 bytes for CJK characters such as 世, and 4 bytes for emoji. That is why Hello (5 bytes) becomes 8 Base64 characters, while 世界 alone (6 bytes) also becomes 8. A tool that skips the UTF-8 step throws on non-Latin text or silently corrupts it.
Base64 is an encoding, not encryption: there is no key, no salt and no protection, so anyone holding the 4n-character string can decode it. Use it to move bytes through text-only systems such as JSON (RFC 8259), XML or email, never to protect a secret.
Base64 encode vs Base64 decode
Encoding and decoding are inverses of the same operation, and mixing up the direction is the usual reason a converter returns an error. Encoding starts from readable text and produces Base64; decoding starts from Base64 and produces readable text.
This page is the encoder. The Base64 Decode pillar page is the decoder and the hub for the whole Base64 collection: it covers JWT segments, data URLs and the error cases that make a decode fail. If you paste text into the wrong direction, the error message usually says so directly — a plain sentence is rarely valid Base64, and a Base64 string decoded as text comes out unreadable.
Where Base64 encoding shows up
Five formats hide Base64. A data: URL carries image or font bytes after a media-type prefix, adding 4 characters per 3 bytes; the 8-byte PNG signature becomes 12 characters. JSON and API fields keep binary in a string value (12 bytes → 16 characters). HTTP Basic auth encodes the 9-byte user:pass as 12 characters. JWT segments are URL-safe Base64 with padding dropped, so the common HS256 header is 27 JSON bytes → 36 characters. MIME email wraps each 57-byte chunk into a 76-character line.
Encoding Base64 in code
The algorithm is identical everywhere; the trap is that some functions expect bytes and some expect text. In JavaScript, btoa alone only accepts code units up to 0xFF (255), so encode with TextEncoder first and spread the result in chunks of 0x8000 (32,768) for large inputs. Node accepts text directly with Buffer.from(text, 'utf8').toString('base64'). Python needs bytes: base64.b64encode(text.encode('utf-8')).decode('ascii') raises a TypeError without the encode step. PowerShell uses [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($text)), where GetBytes is UTF-8 in this example but other .NET encodings produce different bytes. Java uses Base64.getEncoder() for standard output and getUrlEncoder() when the value will sit in a URL or JWT and the 0–2 padding chars should be dropped.
One check applies to all 5 languages: encode a 5-byte ASCII string such as Hello and confirm the output is 8 characters ending in = (1 padding character). If a library returns a different count, it is encoding characters instead of UTF-8 bytes.
Edge cases worth knowing
- Empty input. 0 bytes encode to 0 characters, not to
====; an empty string is a valid Base64 value. - Padding boundaries. 1 byte produces 4 chars ending
==; 2 bytes produce 4 chars ending=; 3 bytes produce 4 chars with no padding. - MIME boundary. 57 bytes is exactly one 76-character line; 58 bytes moves to a second line. JSON fields and data URLs should stay on one line instead.
- JavaScript length trap.
"👋".lengthis 2 UTF-16 code units but the emoji is 4 UTF-8 bytes, so measure bytes withTextEncoderbefore predicting the Base64 length. - Impossible length. A Base64 value left with a length of
4n+1after whitespace is removed cannot be decoded, because one character is missing.
When not to use Base64
Base64 is not encryption: a password wrapped in it is still a plain secret, and HTTP Basic authentication sends those 12-char credentials to every proxy that sees the request. It is not compression either, so 1 MB of data becomes about 1.33 MB of text and costs 33.3% more storage, not less.
Choose the variant deliberately. Standard Base64 uses + and /, which clash with URL syntax; URL-safe Base64 replaces exactly those 2 symbols with - and _ and often drops the 0–2 padding characters, which is why JWT segments look different from the text on this page. Do not add line breaks unless the receiver expects MIME wrapping at 76 characters — JSON fields and data URLs should stay on one line.
Frequently asked questions
Is Base64 encoding the same as encryption?
No. Encoding changes how bytes are written; it does not protect them. Anyone with the Base64 string can decode it without a key, so it should never be used for passwords, tokens or personal data. Its only job is to carry data through text-only channels such as JSON, email or a URL.
How do I encode Chinese characters or emoji to Base64?
The text has to be turned into UTF-8 bytes before Base64 is applied, and this tool does that automatically. For example, Hello, 世界! encodes to SGVsbG8sIOS4lueVjCE=, and Hugs 👋 encodes to SHVncyDwn5GL. A broken result usually means the source tool treated the string as Latin-1 instead of UTF-8.
Why does btoa throw an error on Chinese text?
btoa encodes a binary string, not a JavaScript string; it only accepts code units up to 0xFF. Chinese, Japanese and emoji exceed that range, so the call raises an InvalidCharacterError. Encode to bytes with TextEncoder first, then build a binary string and pass that to btoa, which is exactly what this page does.
Should I use standard or URL-safe Base64?
Use standard Base64 for JSON, email and data URLs. Use URL-safe Base64 (- and _ instead of + and /, padding optional) when the value will appear in a URL, a filename or a JWT segment. Some decoders accept only one variant, while this site's decoder accepts both.
Does the encoder add line breaks?
No. The output is one continuous string, which is what JSON fields, data URLs and authorization headers expect. MIME Base64 in email is the exception: it wraps at 76 characters, and the matching decoder on this site ignores those line breaks.