Base64 Encoder/Decoder

Base64 Encoder/Decoder - Encode and Decode Base64 Online

A powerful online Base64 encoder and decoder tool that allows you to easily encode text to Base64 format or decode Base64 strings back to plain text. Features multiple character set support (UTF-8, ASCII, UTF-16LE, ISO-8859-1), URL-safe encoding, data: URI generation for images and files, optional 76-char MIME/PEM line wrapping, and instant conversion. Perfect for developers, system administrators, and anyone working with Base64 encoding in web development, APIs, or data transmission.

What is Base64 and when do I use it?

Base64 is a binary-to-text encoding scheme defined in RFC 4648 that represents arbitrary 8-bit bytes using a 64-character alphabet (A-Z, a-z, 0-9, + and /). It is not encryption — it adds zero confidentiality. You use it when you need to transport or embed binary data inside a text-only channel: email bodies (MIME, RFC 2045), HTTP basic auth headers, JSON or XML payloads, data: URIs for inline images in HTML and CSS, JWT segments, PEM-wrapped keys and certificates, and database columns that only accept text. Every three input bytes become four output characters, so the encoded form is roughly 33% larger than the source. If your data is already text, do not Base64-encode it — you waste bytes and break human readability.

Why is the output 33% bigger than my input?

Base64 maps every 3 bytes (24 bits) to 4 characters of 6 bits each, yielding a 4:3 expansion ratio of about 1.333. If your input length is not a multiple of 3, the encoder pads the final group with one or two = characters so the output length is always a multiple of 4. For typical payloads this means roughly 33% overhead, plus a few bytes of padding. For very small inputs the relative overhead is larger; for a single byte you get 4 characters (300% expansion). If size matters, consider Base85/Ascii85 (about 25% overhead) or raw binary transport. For binary already inside gzip or modern image formats, the post-Base64 size may exceed the original by exactly that 33%, so re-compressing the Base64 string almost never helps.

What is the difference between standard Base64 and URL-safe Base64?

Standard Base64 (RFC 4648 section 4) uses + and / as the last two alphabet characters and = for padding. Those three symbols collide with reserved characters in URLs, query strings, and filenames. URL-safe Base64 (RFC 4648 section 5) substitutes - for + and _ for /, and often drops the trailing = padding entirely. The decoded bytes are identical — only the alphabet differs. JWT tokens, OAuth state, and most modern web APIs use the URL-safe variant. If you decode a string that contains - or _ with a standard decoder you will get garbage or an error. Make sure your encoder and decoder agree on the alphabet, and if you strip padding on encode you must re-add it on decode to bring the length back to a multiple of 4.

Can Base64 handle Unicode strings or only ASCII?

Base64 operates on bytes, not characters, so the question reduces to: how is your string converted to bytes before encoding? The universal answer is UTF-8 (RFC 3629). Encoding the string "café" first becomes the bytes 63 61 66 C3 A9 in UTF-8, then Base64 produces "Y2Fmw6k=". A decoder that interprets those same bytes back as UTF-8 will return "café" correctly. If sender and receiver disagree on the text encoding — say one uses UTF-8 and the other Latin-1 — the round trip produces mojibake. This tool uses UTF-8 throughout. When debugging international text, verify the byte sequence first with a hex viewer, then check the Base64 output; this isolates whether the bug is in encoding or in transport.

Why do I get "invalid character" errors when decoding?

The standard alphabet has exactly 64 characters plus = for padding. Any other byte — newline, space, tab, smart quote, emoji, or a + that was helpfully turned into a space by a URL parser — will fail strict decoding. Common causes: (1) the string was transported through a system that line-wraps at 76 characters per MIME convention but the decoder is not in MIME-tolerant mode; (2) a URL form treated + as a space; (3) the string came from an HTML attribute where & was entity-encoded; (4) padding = was stripped en route. Fixes: strip whitespace before decoding, replace spaces with +, re-add trailing = to make length a multiple of 4, and confirm the alphabet (standard vs URL-safe). This tool handles whitespace stripping automatically but warns on truly invalid bytes.

Is Base64 considered encryption or any form of security?

No — Base64 is encoding, not encryption. The transformation is fully reversible without any key, and every Base64 decoder on Earth can read your output. Treating Base64 as a way to "hide" passwords, API keys, or PII is one of the most common security mistakes in code reviews. HTTP Basic auth, for example, sends credentials as Base64("user:password") — which is why Basic auth requires HTTPS to be safe at all. If you need confidentiality, use real cryptography: AES-GCM or ChaCha20-Poly1305 for symmetric encryption, RSA-OAEP or X25519 for key exchange, and a vetted library (libsodium, Web Crypto API, OpenSSL). Base64 still has a legitimate role wrapping the resulting ciphertext for transport, but it never provides security on its own.

How do I stream-encode a large file without loading it into memory?

Base64 is block-friendly because every 3 input bytes map cleanly to 4 output characters, so you can encode in chunks as long as each chunk is a multiple of 3 bytes (except the final chunk, which receives the padding). In Node.js, pipe the file through fs.createReadStream into a Transform that calls Buffer.toString('base64') on each multiple-of-3 chunk. In Python, use base64.encodebytes on iterated reads of, say, 57 KB (multiple of 3, fits in MIME 76-char lines). In the browser, the FileReader.readAsDataURL API handles this for you, but for huge files prefer Blob.stream() with a TransformStream. Avoid the trap of encoding chunks independently and concatenating: if any chunk size is not divisible by 3, the padding = in the middle corrupts the output. Always defer padding until the final chunk.

What is Base64URL with no padding, and why does JWT use it?

JWT (RFC 7519) and JOSE (RFC 7515) specify base64url-encoded segments with all = padding stripped. The reason is purely cosmetic and operational: tokens travel in URLs, HTTP headers, and cookies where = either needs percent-encoding (=%3D) or triggers parsers expecting key=value pairs. Removing padding shortens tokens by 1-3 characters and avoids the escaping headache. To decode, you must re-add padding so the string length becomes a multiple of 4: append "", "==", or "=" depending on length mod 4. Most JWT libraries do this for you, but if you decode manually with Buffer.from(str, 'base64url') in modern Node 16+ it just works. In browsers, atob() does not understand the URL-safe alphabet, so replace - with + and _ with / before calling it, then re-add padding.

How do I turn an image or file into a data: URI?

A data: URI inlines a file directly into HTML, CSS, or SVG so the browser needs no extra HTTP request. The syntax is data:<mime-type>;base64,<base64-payload> — for example data:image/png;base64,iVBORw0KGgo... To build one here, drop or pick a file in the encode panel and tick "Output as data: URI"; the tool detects the MIME type from the file and prepends the correct data:<mime>;base64, prefix, giving you a copy-ready string. Paste it into a CSS background-image: url(...), an <img src>, or an SVG <image href>. Keep inlined assets small (under ~10 KB is a good rule) because Base64 adds ~33% overhead and inlined bytes are re-downloaded on every page load instead of being cached separately. To go the other way, paste a full data: URI into the decode panel — the leading data:...;base64, prefix is stripped automatically before decoding.

Why does my MIME or PEM Base64 have line breaks, and how do I handle them?

MIME (RFC 2045) mandates wrapping Base64 at 76 characters per line, and PEM (RFC 7468) wraps key and certificate bodies at 64 characters between the -----BEGIN----- and -----END----- markers. Those hard line breaks are legal Base64 whitespace, not data — a correct decoder must ignore them. This tool strips all whitespace before decoding, so wrapped MIME, PEM, and email-sourced Base64 round-trip cleanly. When you need to produce wrapped output yourself (for an email part or a PEM block), enable "Wrap lines at 76 chars" on encode; note that URL-safe output is never wrapped, since newlines are illegal in URLs and tokens. If a third-party parser rejects your wrapped string, it is likely in strict (non-MIME) mode — feed it a single unwrapped line instead.

Key Features

• Encode text to Base64 format instantly
• Decode Base64 strings back to original text
• Support for multiple character sets (UTF-8, ASCII, UTF-16, ISO-8859-1)
• URL-safe Base64 encoding option
• Automatic whitespace and padding handling
• Real-time size comparison statistics
• One-click swap between encode and decode modes
• Copy encoded/decoded text to clipboard
• Download results as text files
• Upload text files for encoding/decoding
• Dark mode support
• 100% client-side processing - your data never leaves your browser
• Encode files up to 10 MB
• Generate ready-to-paste data: URIs for images and files
• Optional 76-char line wrapping for MIME and PEM output
• Works offline after initial load
• Mobile-friendly responsive design
• Clear error messages for invalid Base64 input
• Support for Unicode and emoji characters
• No registration or login required