Base64 Encoder / Decoder

Encode plain text to Base64 or decode Base64 strings back to text. UTF-8 safe — handles emojis and non-ASCII characters correctly.

• ✅ Bidirectional (encode / decode)
• ✅ UTF-8 aware — works with Chinese, emojis, accented characters
• ✅ Auto-detects invalid Base64 input
• ✅ 100% in browser

Common use cases

• Reading HTTP Basic credentials. The Authorization: Basic header is just Base64 of username:password; decoding it here reveals the pair instantly, which is exactly why Basic auth must always travel over TLS.
• Inspecting JWT claims. After converting the URL-safe characters back to the standard alphabet, the middle segment of a JSON Web Token decodes to readable claims such as issuer, subject, and expiry.
• Embedding assets as data URIs. Small SVGs, icons, or fonts can be inlined into CSS or HTML as data: URLs whose payload is Base64, avoiding an extra request at the cost of larger markup.
• Debugging MIME email. Raw message bodies and attachments in quoted printable or Base64 form can be pasted here to recover the original text.
• Passing text through byte-oriented configs. Environment variables, Kubernetes secrets, and CI variables commonly expect values in Base64 so that newlines and special characters survive transport.

How to use

1. Pick Encode or Decode in the mode toggle at the top left. The input and output labels switch to match.
2. Paste plain text (in Encode mode) or a Base64 string (in Decode mode) into the left editor. Conversion runs as you type; there is no submit button.
3. Read the result in the right panel and press the copy button above it to place the output on your clipboard.
4. Check the status bar beneath the editors: it confirms success and reports the byte count of the input or the decoded output.
5. If the input cannot be converted, a red banner explains why, for example invalid Base64 characters or decoded bytes that are not valid UTF-8 text.
6. Use Sample to load example content for the current mode and Clear to empty the editor.

Tips and pitfalls

The padding characters are structural, not decoration. Base64 consumes three bytes at a time and emits four characters, so an input whose length is not a multiple of three ends with one or two = signs to round out the final quartet. Stripping them, as JWTs do, produces a length that strict decoders like the browser’s atob may reject, so restore the padding before decoding. In the other direction, this tool is forgiving about whitespace: line breaks and spaces are removed before decoding, which makes PEM-style wrapped output paste cleanly.

Watch for the URL-safe variant defined in RFC 4648 section 5. It swaps + for - and / for _ so the result can sit inside URLs and filenames without escaping. Standard decoders treat those two characters as invalid, so a token copied from a URL often fails until you swap them back. This is the single most common reason a string that “looks like Base64” refuses to decode.

Unicode requires an explicit byte encoding step. The naive approach of calling btoa directly on a JavaScript string throws on anything outside Latin-1, because btoa expects a binary string of byte values. This tool routes input through TextEncoder first, so emoji and CJK text round-trip correctly; the byte count in the status bar is the UTF-8 length, which is why a single emoji counts as four bytes.

FAQ

Is Base64 a form of encryption?

No. Base64 is a reversible encoding with no key and no secrecy: anyone can decode it instantly. Its purpose is to carry binary or text data through channels that only tolerate printable ASCII, such as email bodies and JSON fields. Never treat Base64 output as protected data.

Why does Base64 output sometimes end with = or ==?

Base64 processes input in groups of three bytes and emits four characters per group. When the input length is not a multiple of three, the final group is padded with one or two equals signs so the output length stays a multiple of four. One padding character means the input had a remainder of two bytes; two means a remainder of one.

Why is Base64 output about 33 percent larger than the input?

Each group of three input bytes (24 bits) is split into four 6-bit values, each stored as one ASCII character (8 bits). That 24-to-32-bit expansion is an exact 4/3 ratio, or roughly 33 percent overhead, before any line wrapping. The status bar reports the UTF-8 byte count so you can see the growth directly.

Can this tool decode a JWT?

Mostly, with one adjustment. JWT segments use the URL-safe Base64 variant, which replaces plus with hyphen and slash with underscore, and the padding is usually stripped. Replace hyphens with plus signs and underscores with slashes, add equals signs until the length is a multiple of four, then decode. The middle segment decodes to readable JSON claims.

Why does decoding fail with an error even though the string looks like Base64?

Common causes are URL-safe characters (hyphen or underscore) that the standard alphabet rejects, a length that is not a multiple of four because padding was stripped, or bytes that decode to something other than valid UTF-8 text. This tool is text-oriented, so decoding Base64 of a binary file such as an image will report that the result is not valid UTF-8.

Does the encoder handle Unicode text like emoji or CJK characters?

Yes. Input is first converted to UTF-8 bytes with TextEncoder and then encoded, and decoding reverses the process with a strict UTF-8 TextDecoder. The native btoa function alone would throw on characters outside Latin-1, which is why the UTF-8 intermediate step matters.