The Base64 Encoder/Decoder converts text and files to and from Base64, a text-safe encoding used everywhere from HTTP Basic auth headers to data URIs, JWT payloads, PEM certificates, email attachments, and OAuth callback state. Paste text to encode it, paste Base64 to decode it, or upload a binary file (image, PDF, key file) and get a copy-ready Base64 string. Supports the standard alphabet and the URL-safe variant (RFC 4648 §5, with -/_ instead of +//), optional MIME line wrapping (64 or 76 characters), padding toggle, and both UTF-8 and Latin-1 character sets. Everything runs in your browser — nothing is uploaded.
What is Base64 and when do you use it?
Base64 is a text-safe encoding that represents arbitrary bytes using only 64 printable ASCII characters: A–Z, a–z, 0–9, and two symbols (+ and / for standard, - and _ for URL-safe). It exists so binary data — images, PDFs, encryption keys, protocol buffers — can travel through channels that only accept text: HTTP headers, JSON payloads, XML documents, email bodies, URLs, and cookies. You encounter Base64 in HTTP Basic auth (Authorization: Basic dXNlcjpwYXNz), in JWTs (three Base64URL segments separated by dots), in data URIs (data:image/png;base64,…), in PEM-encoded certificates, and in MIME email attachments. The trade-off: Base64 is ~33% larger than the original bytes, so it's used for transport safety, not for compression.
Standard Base64 vs. URL-safe Base64
There are two common alphabets. Standard Base64 (RFC 4648 §4) uses + and /. Those characters are unsafe in URLs (+ means a space in a query string, / is a path separator) and inconvenient in filenames. URL-safe Base64 (RFC 4648 §5) swaps them for - and _, which are safe in URLs and filenames without escaping. JWTs use URL-safe Base64 without padding. If you're encoding for a URL, cookie value, filename, or JWT payload, choose URL-safe. If you're producing a PEM block or a MIME attachment, choose standard. The decoder in this tool accepts both — it normalises -/_ back to +// before decoding.
Padding, line wrap, and MIME
Base64 encodes 3 bytes at a time into 4 characters. If the input length isn't a multiple of 3, the output is padded with = so its length is a multiple of 4: one = for two remaining bytes, two =s for one remaining byte. Padding makes decoders simpler because they can rely on a fixed alignment. Some contexts — URLs, JWTs, and any transport where = is inconvenient — drop the padding, and decoders must add it back mathematically. This tool lets you toggle padding on or off for the encoded output. MIME line wrapping (RFC 2045) requires that Base64 lines be at most 76 characters long, separated by CRLF. Older PEM formats use 64. Set the wrap length in the settings panel; for URL contexts, keep it off (one long line).
UTF-8, Latin-1, and how text becomes bytes
Base64 doesn't operate on text — it operates on bytes. So before encoding text, we have to decide how to turn characters into bytes. The default here is UTF-8, the encoding used by ~98% of the web: it represents ASCII as one byte, and non-ASCII characters (accents, emoji, CJK) as two-to-four bytes. This is almost always what you want. Latin-1 (ISO-8859-1) is a legacy 8-bit encoding where every character is exactly one byte; it's only correct for text that contains no characters above U+00FF. Old JavaScript code sometimes uses Latin-1 implicitly (that's what the built-in btoa() does — which is why btoa('café') throws). This tool uses TextEncoder/TextDecoder to do UTF-8 correctly, so emojis and accented characters round-trip cleanly.
Encoding and decoding files
Click the upload icon to encode a binary file (image, PDF, key file, anything). The tool reads the raw bytes with FileReader.readAsArrayBuffer and produces a Base64 string you can paste into a data URI, an API request body, or a config file. In decode mode, upload works too — but it expects the file to contain Base64 text, and it will decode the bytes back into the output pane, ready to download as a binary file. Everything happens in your browser: the file is never sent to any server, which matters for private keys, unreleased assets, or medical images. For very large files (tens of MB) the browser tab may briefly become unresponsive while encoding — Base64 is CPU-cheap but the resulting strings are ~4/3 the size of the input.