Base64

Base64 is an encoding scheme that represents arbitrary binary data using 64 ASCII characters: the uppercase letters A-Z, the lowercase letters a-z, the digits 0-9, and the symbols + and /. Padded with the = character to a multiple of 4 bytes. Defined in RFC 4648.

Three input bytes encode to four Base64 characters, so the encoded form is roughly 33% larger than the source. Encoding and decoding are both deterministic and exact — there’s no quality loss, just size inflation.

The primary use cases:

• Inlining binary data in text-only protocols. Email (MIME attachments), JSON (where binary fields aren’t allowed natively), data URIs in HTML/CSS.
• JWT (JSON Web Token). JWT payloads are Base64-encoded (specifically base64url, see below) to fit safely inside HTTP headers and URLs.
• Storing binary in databases or config files when the native column type would be awkward (e.g. SQLite BLOB columns are fine but require driver-level handling; a TEXT column holding Base64 is more portable).

Base64url is a variant defined in the same RFC that replaces + with - and / with _. These two substitutions make the encoded data URL-safe — neither - nor _ needs percent-encoding in a URL. JWT and modern web APIs use base64url throughout.

Encode or decode in your browser with our Base64 tool, which handles UTF-8 text correctly (the JavaScript btoa / atobprimitives don’t).

Worked example

Encode the three-byte ASCII string “Man”. Bytes are 0x4D 0x61 0x6E, or in binary 01001101 01100001 01101110. Concatenate the 24 bits and split into four 6-bit groups: 010011 010110 000101 101110 = 19, 22, 5, 46. The Base64 alphabet maps those indices to T, W, F, u — producing “TWFu”. No padding required because the input length (3 bytes) was already a multiple of 3. Now encode “Ma” (2 bytes): bits are 01001101 01100001, padded with two zero bits to make 18 bits, split into three 6-bit groups 010011 010110 000100 = 19, 22, 4 = T, W, E. Add one = to mark the missing third character of the group: “TWE=”. Decoding reverses the process and discards the padding. The 33% size inflation is exactly the ratio 4/3 — every 3 bytes of input become 4 bytes of output.

When and why it matters

Base64 matters whenever binary data has to travel through a channel that mangles non-printable bytes — SMTP email (designed for 7-bit text), URL query strings, JSON values, XML CDATA sections, environment variables, YAML config files, and clipboard transfers across encoding-mismatched systems. The classic mistake is using Base64 where it’s not needed: a binary blob stored in a Postgres bytea column doesn’t need encoding because the protocol handles binary natively, but the same blob inserted via a SQL string literal does need it. The second classic mistake is the opposite — embedding a JPEG as a data URI in CSS using Base64 to avoid an HTTP request, then discovering the inflated file is larger than the network savings on HTTP/2 multiplexed connections. Modern image inlining policies typically draw the line around 4-8 KB. Reference: RFC 4648 — Base16, Base32, and Base64 Data Encodings.

Padding and the "=" characters at the end: because Base64 packs every 3 input bytes into 4 output characters, inputs whose length isn’t a multiple of 3 produce 1 or 2 padding characters at the end. YQ==decodes to a single byte ("a"); YWI=decodes to two bytes ("ab"); YWJjdecodes to three bytes ("abc") with no padding. Many Base64 parsers accept input without padding even though strict RFC compliance requires it — base64url in JWT contexts deliberately omits padding. Always check whether your encoder/decoder pair agree on padding, especially when bridging strict and lenient implementations.

Why Base64 is not encryption:Base64 is a deterministic mapping anyone can reverse with no key. Pasting a Base64 string into an online decoder reveals the plaintext immediately. It’s an encoding (a representation change), not an encryption (a confidentiality transform). Storing passwords, API keys, or PII as Base64 in any file that could be read by an attacker is functionally equivalent to storing them in plain text. For confidentiality, use proper encryption (AES-GCM, ChaCha20-Poly1305) with a real key-management story before any Base64 wrapping. Reference: RFC 4648 — Base16, Base32, and Base64 Data Encodings.