What is Base64 encoding?

Base64 is a binary-to-text encoding scheme that represents binary data using 64 printable ASCII characters (A–Z, a–z, 0–9, +, /). It is used to safely transmit binary content - such as images, files, or arbitrary bytes - over channels that only handle text, like email, JSON, or HTML attributes.

What is the difference between Standard, URL-safe, and Base64url?

Standard Base64 uses + and / as the 62nd and 63rd characters, and = for padding. URL-safe Base64 replaces + with - and / with _ so the output can be used in URLs and filenames without percent-encoding. Base64url is the same substitution plus the = padding is removed, making it safe for URL path segments and query parameters - it is the variant used by JWTs.

Does Base64 compress data?

No. Base64 expands data by roughly 33%: every 3 bytes of input become 4 characters of output. It is a pure encoding scheme, not a compression algorithm. If you need smaller output, compress the data first (e.g., gzip), then Base64-encode the compressed result.

Is Base64 the same as encryption?

No. Base64 is trivially reversible - anyone can decode it instantly. It provides no confidentiality. Use Base64 only when you need to represent binary data as text, not to hide information.

Why does my decoded output show garbage?

If the Base64 you are decoding encodes binary data (images, PDFs, compiled files), the decoded bytes will not be valid UTF-8 text. Use the "Download as file" button to save the binary result instead of viewing it as text.

Base64 Encoder / Decoder

What is Base64?

Base64 is a binary-to-text encoding scheme that represents binary data using 64 printable ASCII characters: the uppercase and lowercase alphabet (A–Z, a–z), digits (0–9), and the symbols + and /. A 65th character, =, is used for padding. The name comes from the 64 printable characters used as the encoding alphabet.

Because every byte in the original data is represented by roughly 1.33 characters of output (4 output characters per 3 input bytes), Base64 expands data by about 33%. It is not a compression algorithm; it is a way to safely represent arbitrary binary data in contexts that only support plain text, such as email (MIME), HTML data URIs, JSON, XML, and HTTP headers.

Base64 variants

Standard (RFC 4648 §4)

The classic Base64 alphabet uses + and / as the 62nd and 63rd characters, with = padding to make the output length a multiple of 4. This is the variant produced by btoa() in JavaScript and by most Base64 libraries by default. It is used in MIME email attachments, PEM certificates, and general data encoding.

URL-safe Base64 (RFC 4648 §5)

URL-safe Base64 replaces + with - and / with _, making the output safe for use in URLs and filenames without percent-encoding. Padding is kept. Use this variant when embedding Base64 in a URL query parameter or when storing Base64 in a filename.

Base64url (no padding)

Base64url is URL-safe Base64 with the = padding characters removed. This is the variant mandated by the JWT (JSON Web Token) specification (RFC 7519) for encoding the header, payload, and signature. It is also used in OAuth PKCE, WebAuthn, and other modern web authentication protocols.

Common use cases

Embedding images in HTML/CSS: inline a small image as a data:image/png;base64,… data URI to eliminate an extra HTTP request.
JWT tokens: JSON Web Tokens encode their header and payload as Base64url, making them URL-safe and human-readable when decoded.
Email attachments (MIME): email protocols were designed for 7-bit ASCII text; Base64 is the standard way to include binary attachments.
API credentials: HTTP Basic Authentication encodes username:password as standard Base64 in the Authorization header.
Cryptographic keys and certificates: PEM format (used by OpenSSL, TLS/SSL, and SSH) wraps Base64-encoded binary keys between -----BEGIN …----- headers.

How this tool handles encoding

Text input is first encoded to UTF-8 bytes using the browser's built-in TextEncoder API, then those bytes are Base64-encoded. This means any Unicode text (including emoji, accented characters, or non-Latin scripts) is handled correctly.

For decoding, whitespace (spaces, tabs, newlines) is stripped before decoding, so you can paste PEM-formatted Base64 with line breaks directly. The decoded bytes are then interpreted as UTF-8 text using TextDecoder with fatal: true: if the bytes are not valid UTF-8 (e.g., a binary file), the decoder reports an error and offers a "Download as file" option to save the raw bytes.

All processing happens locally in your browser. No data is sent to any server.

Why Base64 expands data by 33%

Base64 works by grouping every 3 input bytes (24 bits) into 4 output characters (each representing 6 bits from the 64-character alphabet). The math: 3 bytes × 8 bits = 24 bits -> 4 × 6-bit groups -> 4 Base64 characters. That means every 3 bytes become 4 characters - a 4/3 ≈ 1.333 expansion ratio, or about 33% larger.

If the input length is not a multiple of 3, padding (= or ==) is added to fill the last 4-character block. This is why Base64 output length is always a multiple of 4 (in padded variants).

Inline images: when Base64 helps and when it hurts

Embedding an image as a Base64 data URI (data:image/png;base64,…) eliminates the extra HTTP request that would otherwise be needed to fetch the image file. This can improve performance for very small assets:

Good for: icons and sprites under ~1 KB; images that always load with the page and cannot be cached separately; email HTML where external image requests are blocked.
Counterproductive for: images larger than a few KB. The 33% size increase bloats the HTML/CSS file, which is typically not cached separately. The browser also cannot cache the image independently, so it is re-downloaded on every page load. For larger images, use <img src="…"> with a separate file.