Base64 Encode and Decode Online, with Full UTF-8 Support

Base64 is the duct tape of data transport. It takes any data (text, images, binary files) and converts it into a string of plain, safe characters that can travel through systems designed only for text: URLs, JSON, email, HTML attributes, HTTP headers. If you have ever looked inside a JWT token, an email attachment, or a data URI in CSS, you have seen Base64.

What Base64 is, and what it is not

Base64 represents binary data using 64 safe characters: A-Z, a-z, 0-9, + and /, with = used as padding. The alphabet and padding rules are defined in RFC 4648. Every 3 bytes of input become 4 Base64 characters, which is why encoded output is roughly 33 percent larger than the original.

The most important point: Base64 is encoding, not encryption. It provides no security at all. Anyone can decode a Base64 string instantly, because it is a reversible transformation with no key and no secret. Its purpose is safe transport, not protection.

Mixing the two up is a common mistake. A password or API key that has been Base64-encoded is still in plain sight to anyone who knows what they are looking at, which is most developers. If you need to protect data, you need actual encryption. If you just need data to survive being put in a URL or a JSON string, Base64 is the right tool.

Where you encounter Base64 every day

• JWT tokens: the authentication tokens used by most modern web apps are three Base64 sections joined by dots. Decoding the middle section shows the token's claims, such as user ID, expiry and permissions.
• HTTP Basic Authentication: the Authorization: Basic ... header is just username:password Base64-encoded. That is why Basic Auth should only ever be sent over HTTPS: the encoding hides nothing.
• Data URIs: small images embedded directly in CSS or HTML as data:image/png;base64,... to avoid extra network requests.
• Email attachments: email was designed for plain text, so attachments are almost always sent Base64-encoded inside the message.
• API payloads: binary data inside JSON (which has no binary type) travels as Base64 strings.
• Configuration secrets: Kubernetes secrets, CI/CD variables, and many config systems store values Base64-encoded.

Standard vs URL-safe Base64

Standard Base64 uses + and /, but both characters have special meanings in URLs: + means a space, and / is a path separator. Putting standard Base64 in a URL breaks things.

URL-safe Base64 (defined in RFC 4648) solves this with two substitutions: + becomes - and / becomes _. The trailing = padding is also usually dropped. JWTs use URL-safe Base64, which is why pasting a JWT into a standard decoder sometimes fails.

The Virtual Text Tools Base64 tool has a URL-safe toggle. Turn it on when working with JWTs, URL parameters, or anything that came out of a web address. The tool also automatically restores missing padding when decoding URL-safe input, which is the other common failure point.

The UTF-8 problem most Base64 tools have

This is the technical detail that separates a correct Base64 tool from a broken one.

Browsers have built-in functions for Base64: btoa() to encode and atob() to decode. The catch: they only handle single-byte characters. The moment your text contains an emoji, an accented character like é, or any non-Latin script such as Japanese, Arabic or Cyrillic, raw btoa() either throws an error or quietly encodes the wrong bytes, because those characters are multi-byte in UTF-8.

Many online Base64 tools use these functions directly and inherit the bug. Encode "café ☕" on one of them and you will get an error or garbage.

The correct approach, and the one Virtual Text Tools uses, is to first convert the text to UTF-8 bytes with TextEncoder, then Base64-encode the bytes, and to reverse the process with TextDecoder when decoding. The result: emoji, accents, and every script round-trip perfectly.

// The broken way (fails on emoji and accents):
btoa("café ☕")  // ❌ throws InvalidCharacterError

// The correct way:
const bytes = new TextEncoder().encode("café ☕");
// ...then Base64-encode the bytes  // ✅ works for all text

How to encode or decode Base64

1. Use the Base64 tool at the top of this page
2. Choose Encode (text to Base64) or Decode (Base64 to text)
3. Type or paste your input. The result appears as you type
4. If you are working with a JWT or URL parameter, enable the URL-safe toggle
5. Use Swap to flip the output back into the input and reverse the operation, which is a quick way to check a round trip
6. Click Copy to copy the result

Why decoding fails, and how to fix it

If a Base64 string will not decode, it is almost always one of these:

• It is URL-safe Base64. It contains - or _ instead of + or /. The decoder now detects these characters and converts them automatically, and the URL-safe toggle does the same.
• Missing padding. The string length is not a multiple of 4 because trailing = characters were stripped. The decoder adds the padding back.
• Whitespace or line breaks. Base64 copied from emails or terminal output often has line wraps inserted. The decoder strips all spaces and line breaks before decoding, so wrapped Base64 pastes in as it is.
• It is not actually Base64. Hex strings, URL-encoded text and random tokens can look similar. If it contains characters outside the Base64 alphabet, it is something else.
• It decodes to a file, not text. Base64 often carries images, PDFs or compressed data. The bytes are valid but are not readable text, so the tool says so instead of showing garbled characters.

Why privacy matters for Base64 in particular

Think about what people paste into Base64 decoders: JWT auth tokens, API credentials, Basic Auth headers, config secrets. This is some of the most sensitive material a developer handles, and a server-based tool sees every byte of it.

Virtual Text Tools encodes and decodes entirely in your browser. Your tokens and credentials never leave your device. There is no server request, no logging and no retention. You can verify this in your browser's developer tools: the Network tab shows zero outgoing requests while you work. For anything containing live credentials, keep it that way: do not paste them into a tool that sends input to a server.

Frequently asked questions

Is Base64 encryption?

No. Base64 is a reversible encoding with no key and no secret, so anyone can decode it instantly. Never use it to protect passwords or sensitive data. Its job is safe transport through text-only systems, not security.

Why is Base64 output larger than the input?

Every 3 bytes of input become 4 output characters, so Base64 is about 33 percent larger than the original data. That is the cost of representing arbitrary data using only 64 safe characters.

What is URL-safe Base64?

A variant that replaces + with - and / with _ so the result is safe in URLs and filenames. JWTs use it. Toggle the URL-safe option when encoding for URLs or decoding tokens.

Can I decode a JWT with this tool?

Yes. A JWT is three URL-safe Base64 sections separated by dots. Paste the header or payload section (the first or second part), enable URL-safe mode, and decode to see the JSON inside. You can then paste that into the JSON formatter to read it cleanly.

Does this work with emoji and non-English text?

Yes. The tool uses proper UTF-8 handling via TextEncoder and TextDecoder, so emoji, accented characters, and all scripts encode and decode correctly. Tools built on raw btoa() alone fail on these characters.