Text to Base64 Encoder
Encode any string to Base64 in your browser, with correct UTF-8 byte handling and a standard or URL-safe alphabet, ready to copy or download.
What it does
- UTF-8 by default so accents and emoji round-trip cleanly
- Standard or URL-safe alphabet for JWTs and query params
- Copy to clipboard or download the encoded output
- Runs locally in WebAssembly, nothing is uploaded
Text to Base64 encoding turns any string into the 64-character ASCII alphabet so it survives HTTP headers, JSON values, config files, and data URIs, and it all happens in your browser with no upload. Most people land here to build an HTTP Basic Auth header, drop a value into a config or JSON blob, or stage a JWT segment, often pasting live API keys and credentials they would rather not send to an ad-supported third-party server.
What this conversion actually does (and does NOT do)
Base64 is an encoding, not encryption. It adds zero confidentiality and is trivially reversible by anyone, so it must never be used to "hide" a secret. Its only job is to make arbitrary bytes safe to carry through text-only channels.
The output is always about 33% larger than the input. Every 3 input bytes become exactly 4 ASCII characters, so a 9-byte string becomes 12 characters, a 30-byte string becomes 40, and so on. There is no quality loss and no compression: the bloat is structural. If that Base64 is later served over HTTP with gzip or Brotli, the repetitive patterns compress well and the effective overhead often drops to roughly 5-10%, but the raw string itself is still a third bigger.
Text has to be converted to bytes before encoding, and the byte encoding matters. The string "café" or an emoji encodes to completely different bytes under UTF-8 versus Latin-1, and choosing the wrong one is the single most common cause of garbled round-trips. This encoder uses UTF-8 by default so multi-byte characters survive the trip back.
The trailing = signs are just length alignment, not data. One leftover byte produces ==, two leftover bytes produce a single =, and an exact multiple of three bytes produces no padding at all. Padding can be omitted in contexts where the length is already known, but most decoders expect it. There are also two alphabets: standard Base64 uses + and /, while URL-safe Base64 (RFC 4648 §5, the variant JWTs use) swaps those for - and _ so the string is safe inside URLs, query parameters, and filenames.
One thing this does NOT do by default is insert MIME line breaks. Email-style Base64 wraps a newline every 76 characters, and that whitespace is invalid for many decoders, so it breaks downstream parsing if you paste it into a header or JSON value. Keep wrapping off unless you are specifically feeding an email or PEM consumer that requires it.
When to choose Text to Base64
Reach for Base64 when you have a small text payload that needs to travel through a text-only channel: an HTTP Basic Auth header (the Base64 of user:pass), a tiny config blob, a JSON or localStorage value, or a data URI for a very small asset. Pick the URL-safe alphabet when the result goes into a URL, a query string, a filename, or a JWT; pick standard otherwise. For large binaries the 33% size penalty makes raw binary transfer the better choice, so do not Base64 a multi-megabyte file just to move it. When you need to read a Base64 string back, use the reverse direction with the Base64 encode and decode tool.
How to convert text to Base64
- Open this page, which is locked to encode (text to Base64).
- Pick the alphabet variant: standard for general use, or URL-safe for JWTs, query params, and filenames.
- Paste or type your text into the input field.
- Click convert to produce the Base64 output.
- Copy the result to your clipboard or download it as a file.
No upload. It runs on your device.
This encoder is compiled from Rust to WebAssembly and runs entirely inside your browser tab. Your text is turned into bytes and Base64-encoded locally, with zero network requests, so it keeps working offline once the page has loaded. Nothing is uploaded, which means there is nothing on a server to leak or delete. You can confirm this yourself: open your browser's DevTools, watch the Network tab, and encode a string, no request fires. That matters here because the values people Base64-encode are often the most sensitive strings they handle: API keys, passwords inside Basic Auth credentials, and token payloads that should never be pasted into a third-party site.
No limits
No file-size or character cap, no watermark, no sign-up, no ads, and no tracking. Encode as many strings as you like.
Frequently asked questions
- Is Base64 encoding the same as encryption?
- No. Base64 is a reversible encoding that adds no confidentiality whatsoever, and anyone can decode it back to the original text in seconds. Use it to make bytes safe for text channels, never to protect a secret.
- Why is my Base64 output about a third longer than the original text?
- Base64 maps every 3 input bytes onto exactly 4 ASCII characters, a fixed 4-to-3 ratio that adds roughly 33% in length. The growth is structural rather than a setting, though serving the result with gzip or Brotli can shrink the effective overhead to around 5-10%.
- What do the trailing = signs in Base64 mean?
- They are padding that aligns the output to a multiple of four characters, not part of your data. One leftover byte yields
==, two leftover bytes yield a single=, and an exact multiple of three bytes yields none. - What is the difference between standard and URL-safe Base64?
- Standard Base64 uses the characters
+and/, which can break inside URLs and filenames. URL-safe Base64, defined in RFC 4648 §5 and used by JWTs, replaces them with-and_so the string is safe in URLs, query parameters, and filenames. - How do I encode text with accents or emoji to Base64 correctly?
- Make sure the text is converted to bytes as UTF-8 before encoding, which this tool does by default. "café" or an emoji produces different bytes under UTF-8 versus Latin-1, and mismatched encodings are the top cause of garbled round-trips.
- Does this text-to-Base64 tool upload my text to a server?
- No. The encoding runs in WebAssembly inside your browser with zero network requests, so your text never leaves the device. You can verify it by watching the DevTools Network tab while you encode, no request is made.
- Should the Base64 output have line breaks every 76 characters?
- Only for email and PEM contexts that expect MIME wrapping. For HTTP headers, JSON values, and data URIs you should leave wrapping off, because the inserted newlines are invalid for many decoders and will break the value downstream.
- How do I create a Base64 value for an HTTP Basic Auth header?
- Concatenate the username and password as
user:passand encode that single string to Base64. The result becomes the credential in anAuthorization: Basic <value>header. - Can I safely Base64-encode an API key or password here?
- Yes, because the encoding happens locally and the value never touches a server. Remember that the resulting Base64 is not encrypted, so anyone who sees it can decode the original key or password.
- How do I decode Base64 back to text?
- Use the reverse direction, which reads a Base64 string and returns the original text. The Base64 encode and decode tool handles both standard and URL-safe input locally.
For the reverse direction and full decode support, use the Base64 encode and decode tool. Browse the rest of the text and data tools, or read why everything here runs privacy-first in the browser.