[INPUT_BUFFER]
TEXT:
CHARSET:
UUID: 0x0000
[OUTPUT_BUFFER]

Protocol

RFC 4648 compliant. Supports Standard Base64, URL-safe variant, Base85, Z85, Base91, Base122 and Hex encoding for maximum interoperability.

Security

Client-side processing only. Zero payload transmission to external servers. [SECURE: TRUE]

rss_feed Signal Link

Technical notes on development, security and tooling. Tutorials and real-world problem solving.

Go to blog arrow_forward

What is Base64 encoding?

Base64 is a method to convert binary data into ASCII text, using 64 printable characters. It's needed when transmitting binary data over text-only channels (email, JSON, URLs).

Supported variants

Standard Base64 (RFC 4648)

Uses characters A-Z a-z 0-9 + / with = padding. Standard for email (MIME), HTTP basic auth, data URIs.

URL-safe Base64

Replaces + with - and / with _ to be safe in URLs and filenames. Used in JWT, OAuth tokens, modern APIs.

Base64 without padding

Removes trailing = characters. Preferred in systems that don't handle padding well, like some JWT implementations.

Base85 (RFC 1924)

Converts 4-byte groups into 5 printable characters (80% efficiency versus Base64's 75%). Uses the RFC 1924 alphabet, the same used by Git and Python's b85encode. Trailing partial groups are handled without explicit padding, matching Python's b85encode/b85decode scheme.

Z85 (ZeroMQ)

A Base85 variant defined in ZeroMQ's Z85 specification: same 4-byte grouping, a different alphabet designed to be safe inside quotes and in scripting languages. Unlike Base85, Z85 has no partial groups: data length must be a multiple of 4 bytes and the encoded string a multiple of 5 characters.

Base91

A high-performance alternative to Base64 (basE91 by Joachim Henke): processes 13–14 bits at a time, with ~23% overhead versus Base64's ~33%. Useful when every byte counts.

Base122

Encodes 7 bits per character using the full ASCII range (Kevin Albertson's specification). The six problematic characters — NUL, LF, CR, double quote, ampersand, backslash — are carried in two-byte UTF-8 sequences that also carry the following 7-bit chunk, with no efficiency loss. The output is always valid UTF-8, designed for data URIs and automated transport; it may contain control characters and is not suitable for manual copy-paste or channels that normalize, filter or modify text. The most compact format (~14% overhead).

Hex (Base16)

Represents each byte as two hex characters (0-9, A-F). Not Base64, but a common alternative to represent binary data as text, used for hashes (MD5, SHA) and color codes.

Text Encoding

Before applying Base64 or Hex, text must be converted to bytes. The text encoding choice determines how characters are transformed into numbers. Choosing the wrong encoding produces different results, especially with accented characters, symbols, or emojis.

UTF-8 (default)

Modern standard, variable 1-4 bytes per character. Compatible with ASCII for the first 128 characters, represents any Unicode character including emojis and non-Latin alphabets. Use this if you don't know what to pick.

ASCII

Basic English characters only (0-127). More restrictive: if text contains accented characters (à, è, ì) or non-ASCII symbols, encoding fails. Useful for legacy system compatibility.

Latin-1 (ISO-8859-1)

Extends ASCII to 256 characters by adding Western European accents. Historic encoding widely used before UTF-8 adoption, still present in legacy protocols and files.

UTF-16

Uses 2 or 4 bytes per character, with initial BOM (Byte Order Mark). Less common for data transmission, used internally by Windows, Java, JavaScript for strings.

How Base64 works

The process divides data into 3-byte blocks (24 bits) and represents them as 4 characters of 6 bits each. If data isn't a multiple of 3 bytes, padding characters (=) are added. This increases data size by 33%.

When to use it

Important limits

Base64 is not encryption. It's a reversible encoding without a key: anyone can decode a Base64 string. Use real cryptography (AES, ChaCha20) when you need secrecy or integrity.