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 pillar page, Base64 Decoder for JWT and data URL values, or Decode This to detect an unknown format.
What Base64 encoding does to your text
Base64 reads the input as bytes and rewrites every three bytes as four characters from a 64-symbol alphabet: A–Z, a–z, 0–9, + and /. When the byte count is not divisible by three, one or two = signs pad the final group. The output is pure ASCII, so it can pass through JSON, XML, email headers or a URL without a byte being damaged.
Two details explain most surprises. First, the result is about a third longer than the input, because four characters now carry what three bytes carried. Second, characters are not bytes: 你 occupies three UTF-8 bytes, so a Chinese word grows visibly when encoded. For example, Hello, 世界! becomes SGVsbG8sIOS4lueVjCE=. A tool that skips the UTF-8 step either throws an error on non-Latin text or silently corrupts it.
Base64 is an encoding, not encryption. There is no key and nothing is hidden: anyone holding the string can decode it. Use it to move bytes through text-only systems, 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 links to the encoder, the developer decoder and Decode This for unknown strings. 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
Base64 is almost always an implementation detail rather than something you choose. These are the formats where an encoded value is what you actually need to produce.
| Where the value travels | What gets encoded | Example |
|---|---|---|
| data: URL | Image, font or other binary bytes inside HTML or CSS | data:image/png;base64,iVBORw0KGgo… |
| JSON or API field | A binary payload carried in a string field | {"payload": "SGVsbG8g5LiW55WM"} |
| HTTP Basic authentication | username:password after the word Basic | Authorization: Basic dXNlcjpwYXNz |
| JWT segments (URL-safe Base64) | The JSON header and payload | eyJhbGciOiJIUzI1NiJ9… |
| Email attachments (MIME) | File bytes wrapped at 76 characters | Long blocks ending in = or == |
Encoding Base64 in code
The algorithm is identical everywhere; the trap is that some functions expect bytes and some expect text. These are the equivalents of this tool, with the mistake to avoid in each one.
| Language | Encode to Base64 | Watch out for |
|---|---|---|
| JavaScript (browser) | btoa(String.fromCharCode(...new TextEncoder().encode(text))) | btoa alone only accepts Latin-1 and throws on Chinese; spread the bytes in chunks for large inputs |
| Node.js | Buffer.from(text, 'utf8').toString('base64') | Specify utf8 explicitly when the source might be a buffer |
| Python 3 | base64.b64encode(text.encode('utf-8')).decode('ascii') | Encoding to bytes first is mandatory; skip it and you get a TypeError |
| PowerShell | [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($text)) | GetBytes uses UTF-8 here, but other .NET encodings behave differently |
| Java | Base64.getEncoder().encodeToString(text.getBytes(StandardCharsets.UTF_8)) | Use getUrlEncoder() when the value will sit in a URL or JWT |
When not to use Base64
Because Base64 is easy to reach for, it is worth knowing the cases where it is the wrong tool. It is not encryption, so a password or token wrapped in Base64 is still a plain secret; HTTP Basic authentication, for example, sends credentials that any proxy can read. It is not compression either, so encoding a large file before storing it in JSON makes the value about a third bigger, not smaller.
Choose the variant deliberately. Standard Base64 uses + and /, which clash with URL syntax; URL-safe Base64 (RFC 4648 section 5) replaces them with - and _ and often drops padding, which is why JWT segments and query-string values look slightly different from the text on this page. Finally, do not add line breaks unless the receiving format 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.