Text and Base64, Both Directions

How it works

Paste your text into the left pane and pick the direction; the result appears in the right pane as you type. Encoding runs in two steps: the text is turned into UTF-8 bytes, and the 64-character Base64 alphabet is applied to those bytes — which is why accented letters and emoji come back exactly as they went in. Decoding is deliberately forgiving about how the string reaches you: spaces and line breaks are ignored, a leading data:text/plain;base64, prefix is stripped, and the URL-safe characters - and _ are mapped back to + and /. If the string holds a character the alphabet does not use, the message names that character and its position; if the padding sits in the wrong place or the length cannot work out, that is reported separately. When the bytes decode cleanly but are not valid UTF-8, you are told so, because it means what you hold is a file rather than text. The result line shows how many characters became how many bytes and how many Base64 characters, and you can copy the output or download it as a .txt file.

This tool is also known as base64 encode, base64 decode, text to base64, base64 to text, base64 converter.

What is Base64?

Base64 rewrites data in a 64-character alphabet: A-Z, a-z, 0-9, plus + and /. It reads three bytes at a time, splits those 24 bits into four 6-bit groups and writes one character per group, padding the last group with = when the input does not divide evenly. Because the result is printable text, it survives headers, log lines, config files and JSON strings that would mangle raw bytes. The cost is size: about a third more than the original. The detail that matters beyond plain English is that the alphabet applies to BYTES, not characters, so the text has to become UTF-8 first.

What is UTF-8?

UTF-8 stores each character in one to four bytes and is the default encoding of the web. Unaccented English letters take one byte; accented Latin, Greek and Cyrillic letters take two; most CJK characters take three; emoji take four. That is why the character count of a string and its byte count are two different numbers — a 30-character sentence with a few accents can be 36 bytes. The distinction is practical rather than academic: Base64 output size, database column limits and file sizes are all measured in bytes, and the result line here prints both figures.

Is Base64 encryption?

No. Base64 is an encoding, not encryption, and the difference is the key. Encryption needs a secret to reverse; an encoding is a published rule, so anyone holding the string can turn it back in one click — including on this page. Base64 output looks unreadable, which is exactly why it is so often mistaken for a security measure. Running an API key, a password or personal data through Base64 and calling it hidden is a common and dangerous mistake: the value is still there in plain sight, one step away from anyone who copies it. Use Base64 to move data through a channel that only carries text, and use real encryption when the data has to stay secret.

Why btoa breaks on anything but plain ASCII

The browser's built-in btoa function accepts only single-byte values in the 0-255 range. A character such as é or ş takes two bytes in UTF-8, so btoa either throws an InvalidCharacterError or, if the string was first squeezed into Latin-1, encodes the wrong bytes — and whoever decodes it reads mojibake like é back.

This tool never skips the step in between: the text becomes UTF-8 bytes, then the alphabet is applied to those bytes. Decoding runs the same route in reverse, so encoding a string and decoding it again returns the original character for character, emoji included.

Where Base64 strings actually turn up

Base64 was built for channels that carry text but not raw bytes. Today it is used just as often to sidestep a quoting, delimiter or character-set problem in a place that accepts only one line of printable text.

• The user and password pair inside an HTTP Basic Authorization header
• The three segments of a JWT, written with the URL-safe alphabet
• Email attachments and MIME bodies while in transit
• Certificates and private keys pasted into a config file as a single line
• Long values dropped into a JSON field to avoid escaping trouble

Two different things go wrong when decoding

The first is an alphabet error: the string contains a character Base64 does not use, the = padding sits somewhere other than the end, or the length cannot be right. This is nearly always an incomplete copy — check that the trailing = signs came with the rest.

The second is a text error: the string is valid Base64, the bytes come out fine, but they are not valid UTF-8. That means the payload is an image, a PDF or an archive, and no text tool can display it. Decode it to a file instead of a string.

Frequently asked questions

How do I decode a Base64 string?

Paste the string into the left pane and set the direction to decode. Whitespace and line breaks are ignored and a data: prefix is removed for you, so you can paste the string exactly as you found it.

Are URL-safe (base64url) strings supported?

When decoding, yes: - and _ are mapped back to + and /, and missing padding is tolerated. Encoding always produces the standard alphabet, with + and / rather than - and _.

What do the = signs at the end mean?

Base64 reads three bytes at a time and writes four characters. When the final group is short, one or two = signs pad the output to a multiple of four. They are part of the string — dropping them can make decoding fail.

Why is the encoded string longer than my text?

Three bytes always become four characters, so the output is roughly a third larger than the input, plus padding. That overhead is what it costs to move binary data through a text-only channel.

Is the text I paste sent anywhere?

No. Encoding and decoding run inside your browser, so a token, a key or a config file you paste never leaves the page, and the tool keeps working with the network disconnected.