Base64 Encoder / Decoder

Encode text or files to Base64, or decode a Base64 string back to plain text. Supports URL-safe mode and direct file encoding. Everything runs in your browser — nothing is sent to any server.

Plain text
Base64

Related Tools

Frequently Asked Questions

Why does Base64 encoding increase data size, and by exactly how much?

Base64 maps every 3 bytes of binary input to 4 ASCII characters (3 × 8 bits = 24 bits, split into 4 × 6-bit groups). This means output is always ⌈n/3⌉ × 4 characters — exactly 33.3% larger for inputs that are a multiple of 3 bytes, slightly more otherwise due to padding. For a 1 MB image, expect ~1.37 MB after Base64 encoding. This overhead matters when embedding images as data URIs in CSS or HTML: beyond ~1–2 KB, the size penalty usually outweighs the HTTP request savings.

What is the = padding in Base64 and do I always need it?

When the input length is not a multiple of 3 bytes, the final group has 1 or 2 leftover bytes. Base64 pads the output with = (one or two characters) to keep the output length a multiple of 4. Padding is required by MIME and standard Base64, but RFC 4648 §3.2 allows omitting it when the data length is known from context. Base64URL (used in JWTs) omits padding entirely. Most decoders handle both padded and unpadded input — but a missing = that the decoder doesn't handle causes an 'incorrect padding' error, fixed by appending the right number of = signs.

What is the difference between standard Base64 and Base64URL, and when does it matter?

Standard Base64 uses + and / in its alphabet. These characters have reserved meanings in URLs (+ = space in query strings, / = path separator), so a Base64 string placed raw into a URL or cookie will corrupt. Base64URL (RFC 4648 §5) substitutes - for + and _ for /, and omits padding — making it safe for URL query parameters, HTTP headers, cookies, and filenames. JWTs always use Base64URL. If you're encoding data for embedding in a URL, always use Base64URL, not standard Base64.

Can Base64 encode binary files, and how do you decode back to a file rather than text?

Yes — Base64 is a binary-to-text encoding scheme, originally designed for attaching binary files to email via MIME. When decoding, the result is raw bytes, not a UTF-8 string. If you paste Base64-encoded binary (a PDF, PNG, ZIP) and the decoder outputs garbled text, it is interpreting bytes as a text encoding. In JavaScript, atob() returns a binary string; you must convert each character's char code to build a Uint8Array before creating a Blob for file download.

Why does my Base64 output contain line breaks, and do they affect decoding?

The MIME standard (RFC 2045) requires Base64-encoded lines to be no longer than 76 characters, inserting \r\n line breaks at that boundary — designed for email transport. Modern contexts (data URIs, JWTs, JSON values, HTTP headers) expect a continuous string without line breaks. MIME decoders ignore them, but non-MIME decoders may fail or produce incorrect output. If a tool generates Base64 with line breaks and your target system rejects it, strip all whitespace from the encoded string before use.