Rechnerpilot tool

Base64 Encoder

Encode UTF-8 text as standard Base64 or decode Base64 to text.

Developer Tools

Enter text to generate Base64.

Explanation

How Base64 Encoder works

Base64 is an encoding scheme (defined in RFC 4648) that converts byte sequences into a sequence of 64 printable ASCII characters (A-Z, a-z, 0-9, +, /). It encodes 3 bytes (24 bits) into 4 characters (6 bits each) and uses = as padding at the end.

Typical applications are email attachments (MIME, RFC 2045), data URLs for images (data:image/png;base64,...), JWT tokens, PEM certificates, HTTP Basic Authentication, JSON APIs and configuration files. This tool processes only UTF-8 text, not files or arbitrary binary data. The output needs four characters per started group of three input bytes; padding affects short inputs.

Important: Base64 is not encryption. The encoding can be reversed by anyone without a key. Base64-encoded data is just as readable as the original text — merely represented in a different format.

Common mistakes

Confusing Base64 with encryption: Base64 provides no security whatsoever. Anyone can decode the encoded text without a key. For privacy use real encryption (AES, ChaCha20).
Forgetting URL-unsafe characters: Standard Base64 contains + and /, which have special meaning in URLs. For URL contexts use Base64URL (with - and _) or URL encoding.
Confusing text characters with bytes: Unicode characters can occupy multiple UTF-8 bytes; the output length therefore cannot be derived from the JavaScript character count.
“Hiding” sensitive data in Base64: Encoding passwords, API keys or personal data in Base64 offers no protection. In logs, URLs or configurations they are trivially readable.

Limits of this tool

No privacy — Base64 is readable, not encrypted.
Four output characters per started group of three input bytes; padding affects short inputs.
Text input/output only — no file encoding (images, PDFs etc.).
No Base64URL mode (RFC 4648 §5) — only standard Base64 with + and /.
Decoding binary data (non-UTF-8) fails, since only text output is supported.

Sources

RFC 4648: The Base16, Base32, and Base64 Data Encodings. IETF, 2006. Defines standard Base64 and Base64URL.
RFC 2045: MIME Part One — Format of Internet Message Bodies. Defines Base64 for email attachments (Content-Transfer-Encoding).
WHATWG HTML Standard: Definition of btoa() and atob() for Base64 conversions in the browser.
WHATWG Encoding Standard: Definition of TextEncoder, UTF-8 and fatal TextDecoder decoding.

Practice

Practical examples

Encode ASCII

“Hello” is reproducibly encoded as UTF-8 text to “SGVsbG8=”.

Decode Base64

“U3RyYcOfZQ==” is reproducibly decoded to the Unicode text “Straße”.

UTF-8 special characters

German umlauts and special characters are handled correctly as UTF-8.

FAQ

Frequently asked questions

What is Base64?

Base64 is an encoding scheme (RFC 4648) that converts arbitrary data into a sequence of 64 printable ASCII characters (A-Z, a-z, 0-9, +, /) plus padding (=). It is used to transmit binary data in text formats such as JSON, XML or email.

Is Base64 encryption?

No. Base64 is not encryption but a reversible encoding. Anyone can decode Base64 without a key. Base64 provides no privacy or security. Use real encryption (e.g. AES) for confidential data.

Why is Base64 used?

Base64 represents byte sequences with printable ASCII characters. This tool, however, supports only text input and UTF-8 text output, not files or arbitrary binary data.

Is the text sent to a server?

No. Encoding happens locally in the browser using the native btoa()/atob() functions and TextEncoder/TextDecoder. No data is transmitted or stored.

Why does Base64 enlarge the data?

Base64 maps every three input bytes to four characters. For longer byte sequences the overhead approaches one third; for short inputs the padding affects the exact length.

What is the difference between Base64 and Base64URL?

Standard Base64 uses + and / as characters 62 and 63. Base64URL (RFC 4648 §5) replaces these with - and _ to enable URL-safe encoding without additional escaping. This generator uses standard Base64.

How are umlauts and special characters handled?

The encoder processes the text as UTF-8. German umlauts (ä, ö, ü), the ß and emojis are correctly encoded as multi-byte UTF-8 sequences and restored on decoding.

Can I use Base64 for passwords or tokens?

Base64 can serve as a representation format for cryptographic values (e.g. in JWT) but offers no protection itself. The encoded data is trivially readable by anyone.

When does decoding fail?

Decoding fails on invalid characters, impossible length, wrong or non-canonical padding, and on byte sequences that are not valid UTF-8 text. Whitespace and line breaks are removed beforehand.

Where do I encounter Base64 in everyday use?

In data URLs (data:image/png;base64,...), JWT tokens, email attachments (Content-Transfer-Encoding: base64), PEM certificates, HTTP Basic Auth (Authorization: Basic ...) and embedded fonts in CSS.

Tips

Good to know

The output needs four characters per started group of three input bytes.
For passwords or sensitive data: Base64 is NOT encryption.
UTF-8 characters (umlauts, emojis) are handled correctly automatically.

Related calculators