Base64 Encoding Explained: A Developer's Practical Guide
What is Base64, why does it exist, and when should you use it? A clear explanation with examples every developer can understand.

Base64 is one of those encoding schemes every developer encounters but few fully understand. You have seen it in image src attributes, JSON Web Tokens, email attachments, and API authentication headers. If you have ever looked at a JWT and wondered why it starts with eyJ, that is Base64. Here is what it actually is, why it exists, and when you should use it.
What Is Base64?
Base64 is a binary-to-text encoding scheme. It converts binary data (raw bytes) into a string of 64 printable ASCII characters: the uppercase letters A through Z, the lowercase letters a through z, the digits 0 through 9, plus the symbols + and /. The result is safe to transmit anywhere that accepts plain text, even channels that would corrupt raw binary data.
The name "Base64" comes from the fact that the encoding uses 64 distinct characters to represent data, similar to how Base10 (decimal) uses 10 digits and Base2 (binary) uses 2.
Why Does Base64 Exist?
Many systems were originally designed to handle text only. Early internet protocols like SMTP (email), HTTP headers, and XML parsers can all struggle with raw binary data. Control characters, null bytes, and high-byte characters can be misinterpreted, silently dropped, or treated as protocol delimiters.
Base64 solves this by representing any binary data as a sequence of printable ASCII characters that are safe in every text-only context.
The trade-off is size. Base64-encoded data is roughly 33% larger than the original binary. A 100-byte image becomes about 133 characters of Base64. For small pieces of data this is acceptable. For large files it becomes inefficient, which is why Base64 is not used for large file transfers.
How It Works
Every 3 bytes of input become 4 Base64 characters. Here is why: 3 bytes is 24 bits. Split into four groups of 6 bits each, and each 6-bit group maps to one of 64 characters.
Input: "Man" = 77 97 110 = 01001101 01100001 01101110
Groups: 010011 010110 000101 101110
Output: T W F uSo the word "Man" encodes to "TWFu" in Base64.
If the input is not divisible by 3, padding characters (=) are added to make the output length a multiple of 4. You will often see Base64 strings ending in = or == for this reason.
Common Use Cases
Images embedded in HTML or CSS. Small icons and UI elements can be embedded directly as data URIs instead of requiring a separate HTTP request:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..." />This is useful for small images that would otherwise cause an extra network round-trip. For large images, the size overhead of Base64 makes this approach impractical.
JWT tokens. JSON Web Tokens use Base64url (a URL-safe variant that replaces + with - and / with _) for their header and payload sections. When you decode the header of a JWT, you get a JSON object specifying the algorithm:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
decoded: {"alg":"HS256","typ":"JWT"}HTTP Basic Authentication. The Authorization: Basic header encodes credentials in Base64:
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
decoded: username:passwordEmail attachments. The MIME standard encodes non-text email attachments (images, PDFs, Word documents) in Base64 for transport through text-based email protocols.
API responses with binary data. Some APIs return binary data like PDFs or images Base64-encoded inside a JSON response body, because JSON cannot natively contain binary:
{
"filename": "report.pdf",
"content": "JVBERi0xLjQKJeLjz9MK..."
}Base64 Is NOT Encryption
This is the single most important thing to understand about Base64. It is trivially reversible by anyone. There is no key, no secret, and no security whatsoever in the encoding itself. Anyone who sees dXNlcjpwYXNz can decode it to user:pass instantly.
Never use Base64 to "hide" or "protect" sensitive data. Using it for HTTP Basic Auth means the credentials are transmitted in a form that provides zero confidentiality without HTTPS. The transport security (TLS) is what protects the credentials, not the Base64 encoding.
Base64 is an encoding scheme for transport compatibility. It is not encryption, obfuscation, or security in any meaningful sense.
Base64 Variants
Standard Base64 uses + and / as the 62nd and 63rd characters and = for padding.
Base64url replaces + with - and / with _, making it safe for use in URLs and filenames without percent-encoding. This is what JWT uses.
Base64 without padding omits the trailing = characters. Some systems require this format.
Most Base64 tools will handle the standard variant by default, but it is worth knowing the differences when debugging JWT libraries or URL-related encoding issues.
Encode and Decode Instantly
Our tool handles encoding and decoding in your browser with no server involved. Your data stays private because nothing leaves your device.