Why is my encoded string longer than the original?

Standard padded Base64 uses 4 characters for each group of up to 3 input bytes, before line wrapping. One byte becomes 4 characters, two become 4, and three become 4. The overhead approaches 33% for long byte sequences. Multibyte UTF-8 text makes comparison with the original character count misleading.

When should I use the URL-safe variant?

Use it when the receiving URL, filename format or protocol expects base64url, including the usual signed compact JWT. It avoids the standard + and / characters, which can have special meanings in those contexts. It is not interchangeable with standard Base64 everywhere; follow the receiver's padding rules too.

Does Base64 secure my data?

No. It is trivially reversible without any key. Use it for transport only; use real encryption for confidentiality.

Can I encode a file, such as an image?

This tool encodes text. For a binary file you would need the file's raw bytes rather than its text interpretation, a data URL generator is the right tool for embedding images.

Encoders

Base64 Encoder

Encode text or Unicode to standard or URL-safe Base64.

Reverse

LiveCtrl+↵

Input0 lines · 0 chars

Outputbase640 lines · 0 chars

Options

URL-safe variant (base64url)

Uses - and _ instead of + and /, as used in JWTs.

About this tool

Base64 represents binary data using 64 printable ASCII characters, so it can travel safely through channels that expect text: email bodies, JSON fields, HTTP headers, data URLs and XML documents.

Base64 encodes bytes, not characters. This tool converts text to UTF-8 first, so ordinary multilingual text and emoji can round-trip through the paired decoder. This is not a guarantee for every JavaScript string: unpaired UTF-16 surrogates become replacement characters, and the decoder consumes an initial UTF-8 byte-order mark.

How to use it

Paste or upload your textDrop a file onto the input pane, use the file picker, or paste the text directly.
Adjust the options if neededThe defaults suit most input; open Options to change the behaviour.
EncodePress Encode, or use Ctrl+Enter (Cmd+Enter on macOS).
Copy or downloadCopy the result, or download it as a .txt file.

Worked examples

Each example below is executed against this tool by the test suite, so what you see is what the tool actually produces.

Plain ASCII

Input

Hello, World!

Output

SGVsbG8sIFdvcmxkIQ==

Thirteen bytes become 20 characters, padded with == to reach a multiple of four.

Unicode handled as UTF-8

Input

héllo 😀

Output

aMOpbGxvIPCfmIA=

The accented e takes two bytes and the emoji four, so the output is longer than the character count implies.

What to watch for

The details that decide whether a conversion is correct, and where information can be lost without any error being raised.

How the encoding works: Input bytes are taken three at a time, 24 bits, and split into four 6-bit groups, each mapped to one character from A–Z, a–z, 0–9, + and /. Before wrapping, standard padded output has 4 * ceil(byteLength / 3) characters: divide the UTF-8 byte count by 3, round up, then multiply by 4. The increase approaches 33% for long inputs; short inputs can grow much more.
Padding with =: When the byte count is not a multiple of three, standard Base64 ends with one or two = characters so the encoded length stays a multiple of four before wrapping. This tool always retains standard padding. The padding option only affects URL-safe mode, where padding is omitted by default. Follow the receiving format's requirements.
URL-safe Base64 (base64url): The URL-safe alphabet in RFC 4648 replaces + with - and / with _. Padding may be omitted when the receiving format permits it, as in the usual signed compact JWT. A query value does not always require = to be percent-encoded; use a URL or query-string builder and follow the receiver's expected alphabet and padding rules.
Base64 is not encryption: Encoding is fully reversible with no key, so it provides no confidentiality whatsoever. Anyone can decode it instantly. Base64 solves a transport problem, making binary safe for text channels, and nothing more. Never use it to protect a secret.
UTF-8 first, then bytes: The string is converted to UTF-8 bytes before encoding. ASCII uses one byte per code point; é uses two, 中 uses three and 😀 uses four. A visible character can contain several code points, such as a combined accent or an emoji sequence. Base64 expansion depends on bytes, not the number of visible characters.

Limitations

Encodes text, not arbitrary binary files.
Standard padded output approaches 33% overhead relative to input bytes for long inputs; short inputs have proportionally more overhead, and wrapping adds line breaks.
Processing happens in your browser, so very large inputs are bounded by available memory. Files above roughly 10 MB are handled but will feel slower, and multi-hundred-megabyte files are better suited to a command-line tool.

Questions

Why is my encoded string longer than the original?: Standard padded Base64 uses 4 characters for each group of up to 3 input bytes, before line wrapping. One byte becomes 4 characters, two become 4, and three become 4. The overhead approaches 33% for long byte sequences. Multibyte UTF-8 text makes comparison with the original character count misleading.
When should I use the URL-safe variant?: Use it when the receiving URL, filename format or protocol expects base64url, including the usual signed compact JWT. It avoids the standard + and / characters, which can have special meanings in those contexts. It is not interchangeable with standard Base64 everywhere; follow the receiver's padding rules too.
Does Base64 secure my data?: No. It is trivially reversible without any key. Use it for transport only; use real encryption for confidentiality.
Can I encode a file, such as an image?: This tool encodes text. For a binary file you would need the file's raw bytes rather than its text interpretation, a data URL generator is the right tool for embedding images.