Free Base64 encoder / decoder — convert text and files to and from Base64 in the browser.

Six independent classes of functionality. Text and file encode/decode are the table-stakes operations; the URL-safe variant, padding control, character-encoding awareness, and in-browser execution are what make this a developer-grade tool.

Base64 isn't an obscure encoding — it's foundational to the web. Five places you encounter it constantly:

• Email attachments Email transports were originally 7-bit only. MIME Base64-encodes attachments so any byte sequence can be carried over text-only transports. Every email attachment you've ever sent went over the wire as Base64.
• JWTs and OAuth tokens JWT's three parts (header, payload, signature) are all URL-safe Base64. The base64url variant (no `+/`, uses `-_`, no padding) makes the token safe to drop into a URL, header, or cookie. Every JWT you've decoded was Base64-decoded.
• Data URLs and inlined assets `data:image/png;base64,iVBORw0KGgo...` is how you embed an image directly in HTML or CSS instead of a separate file. Useful for inlining small assets, font fragments, or anywhere a single file matters more than the compression overhead.
• API responses that include binary data JSON can't natively carry bytes. APIs that need to include binary (file uploads, image thumbnails, encrypted blobs) encode the bytes as a Base64 string in a JSON field. Standard practice.
• TLS certificates and private keys (PEM) PEM format (`-----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----`) wraps DER-encoded ASN.1 binary in Base64 between header lines. Every cert and key file you've seen with `.pem` is Base64 internally.

Base64 is a simple bytes-to-text encoding. Three input bytes (24 bits) become four output characters (4 × 6 bits = 24 bits). The 64-character alphabet maps each 6-bit value to one character.

• Stage 1 — Collect input bytes Take input as bytes. For text input, the bytes are the UTF-8 (or UTF-16) encoding of the text. For files, the bytes are the file's raw contents.
• Stage 2 — Group into 24-bit chunks Walk the input three bytes at a time. Each 3-byte chunk is treated as a 24-bit value. If the input length isn't a multiple of 3, the last chunk is padded with zero bits (and the output is padded with `=`).
• Stage 3 — Split each chunk into four 6-bit values Each 24-bit chunk gets split into four 6-bit values. 2^6 = 64 — hence Base 64. Each 6-bit value is a number 0-63.
• Stage 4 — Map to the alphabet Standard Base64 alphabet: A-Z, a-z, 0-9, +, /. URL-safe variant replaces `+` with `-` and `/` with `_`. Each 6-bit value maps to one alphabet character.
• Stage 5 — Add padding (or don't) If the input wasn't a multiple of 3 bytes, the output gets padded with `=` so the total length is a multiple of 4. Standard Base64 includes padding. URL-safe Base64 typically strips it (the length is derivable from the string).
• Stage 6 — Concatenate as output All the alphabet characters joined together form the Base64 string. To decode, reverse the process — group input characters by 4, map each to its 6-bit value, concatenate as 24-bit chunks, split into bytes.

Several Base64 variants exist for different contexts. Five most common:

• Standard Base64 (RFC 4648 §4) Alphabet A-Z, a-z, 0-9, +, /. Padded with `=` to 4-character boundary. Used in MIME (email), PEM (certs/keys), HTTP Basic Auth, and most non-URL contexts.
• URL-safe Base64 (RFC 4648 §5) Same alphabet but `+` becomes `-` and `/` becomes `_`. Safe to drop into URLs, filenames, JWT components. Padding is sometimes stripped (length is derivable). Used pervasively in JWT, OAuth, and modern web APIs.
• Base32 and Base16 Other RFC 4648 encodings. Base32 uses A-Z and 2-7 (no easily-confused 0/1/8/B). Less efficient than Base64 (5 bits per character vs 6) but human-readable and OCR-friendly. Base16 is hex — 4 bits per character, the least efficient. Used for cryptographic hash output.
• Base85 / Ascii85 More efficient than Base64 (5 characters per 4 bytes vs 4 characters per 3 bytes). Uses a 95-character alphabet. Common in PDF and PostScript; rare on the web. The tradeoff is poor URL-safety and harder reading.
• MIME Base64 with line breaks RFC 2045 specifies that MIME Base64 should be line-wrapped every 76 characters. Most contexts ignore this — Base64 in a JSON field or HTTP header is one line. PEM files often wrap at 64 characters between BEGIN/END markers. Whitespace is ignored on decode.

Six patterns we see most often:

• What is Base64? An encoding that represents binary data as a string of 64 printable ASCII characters (A-Z, a-z, 0-9, +, /, =). Useful for putting binary into contexts that expect text — email bodies, URLs, JSON fields, source files. Encoding inflates size by ~33% (4 output characters per 3 input bytes). Defined by RFC 4648.
• Is Base64 encryption? No. Base64 is encoding, not encryption. Anyone with the Base64 string can decode it back to the original bytes — no key required. Don't use Base64 to 'hide' sensitive data; it provides zero confidentiality. For actual confidentiality, use real encryption (AES, RSA, etc).
• What's the difference between standard and URL-safe Base64? Standard Base64 (RFC 4648 §4) uses `+` and `/` as part of its alphabet — characters that have special meaning in URLs and require percent-encoding. URL-safe Base64 (§5) replaces them with `-` and `_`, so the encoded output is safe to drop into URLs, filenames, JWT components, etc. JWT uses URL-safe Base64 (also strips the `=` padding).
• Why is the output longer than the input? Base64 encodes 3 input bytes as 4 output characters — a 33% size increase. Plus padding (`=`) at the end if input isn't a multiple of 3 bytes. This is the cost of representing binary as printable text. If size matters, use binary transport (gRPC, raw HTTP upload) instead of Base64-encoding into JSON.
• Why do some Base64 strings end with one or two `=`? Padding. Base64 encodes 3 input bytes at a time, producing 4 output characters. If the input length isn't a multiple of 3, the last group is padded with zero bits and the output gets `=` characters to indicate the padding. One `=` means 1 trailing zero byte (input length mod 3 == 2). Two `==` means 2 trailing zero bytes (input length mod 3 == 1). Strict decoders use the padding to validate length; lenient decoders ignore it.
• Why is my Base64 decode producing garbage? Common causes: (1) the input is URL-safe Base64 but you're decoding as standard (or vice versa) — the `-_` vs `+/` substitution causes a few characters to decode wrong, (2) you have whitespace or line breaks in the input that aren't being stripped, (3) the input was truncated and doesn't decode to a complete byte sequence, (4) the input wasn't Base64 to begin with.
• Can I Base64-encode an entire file? Yes — for any file under 100MB. The tool reads the file in the browser, encodes it, and presents the result. The reverse direction (Base64 → file) also works — paste a Base64 string, decode, download the resulting file. Useful for inspecting Base64-encoded blobs returned by APIs.
• Is this safe? Will my data be uploaded anywhere? No upload. All encoding and decoding happens in your browser. The tool doesn't send your input to any server. Once the page loads, it works offline. You can verify by opening browser dev tools and watching the network tab — no requests fire during encode or decode operations.