Base64 Encoder & Decoder

Convert text to Base64 and back without mangling accents, emoji or any other non-ASCII character. Supports the URL-safe alphabet used by JWTs, and tells you when the input decodes to binary rather than text.

Correct UTF-8 in both directions

Standard and URL-safe alphabets

Accepts missing padding

Byte count for the payload

Everything stays in the browser

How to encode and decode Base64

Pick a direction

Switch between Encode and Decode. Encoding turns readable text into Base64; decoding does the reverse.

Paste your input

Type or paste the text. Conversion runs as you type, entirely in your browser.

Choose the alphabet

Enable URL-safe output when the value goes into a URL, a filename or a JWT. It swaps + and / for - and _ and drops the padding.

Copy the result

Copy the output. If the input was not valid Base64, the error explains exactly which rule it broke.

Base64 is an encoding, not encryption

Base64 turns arbitrary bytes into 64 printable ASCII characters so they can travel through channels that only accept text — email bodies, JSON fields, URLs, HTML attributes. Anyone can reverse it in one step, with no key.

This matters because Base64 gets mistaken for security surprisingly often. A password, an API key or a personal record encoded in Base64 is not protected in any sense; it is merely inconvenient to read at a glance. If the requirement is confidentiality, you need actual encryption.

Why the payload grows by a third

Base64 packs every 3 bytes of input into 4 output characters, so encoded data is about 133% of the original size, plus padding. That overhead is the price of surviving text-only transports.

It is also why inlining large images as data: URIs is a trap: a 300 KB PNG becomes roughly 400 KB of HTML or CSS that cannot be cached separately, cannot be lazy-loaded, and blocks whatever document contains it. Inlining is worth it for tiny icons, rarely for anything else.

Standard versus URL-safe

The standard alphabet uses + and / for its last two characters and = for padding. All three are problematic in URLs: + means a space in query strings, / is a path separator, and = separates parameter names from values.

The URL-safe variant from RFC 4648 replaces + with -, / with _, and usually drops the padding entirely. This is what JWTs use for every segment. This tool accepts both alphabets when decoding and re-adds missing padding automatically, so you can paste a JWT segment directly.

The UTF-8 trap in JavaScript

The browser's built-in btoa() only handles characters in the latin-1 range. Passing it "café" or any emoji throws an InvalidCharacterError, which is why so many hand-rolled implementations quietly corrupt non-English text.

The correct approach — the one used here — is to convert the string to UTF-8 bytes with TextEncoder first, then Base64-encode those bytes, and reverse the process with TextDecoder when decoding. If the decoded bytes are not valid UTF-8, this tool says so instead of returning replacement characters.

Frequently asked questions

Is my text sent to a server?

No. Encoding and decoding happen in your browser with JavaScript. Nothing is transmitted, stored or logged, which matters because Base64 payloads frequently contain credentials or personal data.

Does Base64 encrypt or protect my data?

No. It is a reversible encoding designed for safe transport through text-only channels, and anyone can decode it instantly without a key. Never treat Base64 as a security measure.

What are the = signs at the end?

Padding. Base64 works in 3-byte groups, and when the input length is not a multiple of 3, one or two = characters pad the final group to four characters. The URL-safe variant normally omits them, which is why this tool restores them when decoding.

Why does my JWT segment fail in other Base64 decoders?

Because JWTs use the URL-safe alphabet with - and _ instead of + and /, and they strip the padding. Decoders that only accept the standard alphabet reject them. This tool handles both automatically.

Can I decode a Base64 image here?

You can paste it, but the result will be a message saying the bytes are not valid UTF-8 text — which is correct, since image bytes are not text. This tool converts text; it does not render binary files.

Why did my accented characters turn into question marks elsewhere?

Almost certainly because the encoder used the browser btoa function directly, which only supports latin-1. Non-ASCII characters must be converted to UTF-8 bytes before encoding, which is what this tool does.

Related tools

Developers