Base64 Encoder / Decoder

Base64 shows up in places most people never look: the long string of characters inside a JWT token, the data URI that embeds an image directly in a CSS file, the encoded attachment in an email header, the API response that wraps binary data in a format safe for JSON. It is one of those foundational encoding schemes that quietly underpins a huge amount of how the web works, and understanding it makes debugging a wide range of real-world problems considerably faster.

How to use this tool

1. Choose Encode or Decode mode.
2. Paste your text into the input box.
3. Turn on URL-safe if the result needs to go directly into a URL or filename.
4. Copy the result, or click Swap to feed the output back in and reverse the operation.

What Base64 encoding actually is

Base64 is a binary-to-text encoding scheme. Its job is to take arbitrary binary data, which can contain any byte value including ones that are invisible, non-printable, or have special meaning in certain contexts, and represent it using only 64 printable ASCII characters. Those 64 characters are the uppercase letters A through Z, the lowercase letters a through z, the digits 0 through 9, and two additional characters, the plus sign and the forward slash in standard Base64, or the hyphen and underscore in URL-safe Base64.

The name comes directly from this 64-character alphabet. Each Base64 character represents exactly 6 bits of binary data, since there are 64 possible values for a 6-bit number. The encoding works by taking 3 bytes of input, which is 24 bits, and rewriting them as 4 Base64 characters, each representing 6 bits. When the input length is not a multiple of 3, one or two equals signs are appended as padding to make the output length a multiple of 4. This is why Base64 strings frequently end with one or two equals signs.

The consequence of this 3-to-4 byte mapping is that Base64 encoding makes data approximately 33 percent larger than the original. Three input bytes become four output characters. This size overhead is the main cost of Base64, and it is why Base64 is used specifically when the constraint is format compatibility rather than size efficiency.

Why Base64 exists and what problem it solves

The specific problem Base64 solves is transporting binary data through systems that were designed to handle only text. Email was historically the most significant example: the original SMTP email protocol was designed to carry 7-bit ASCII text, and binary attachments like images or documents cannot be transmitted directly through such a system without corruption. Base64 became the standard solution for email attachments precisely because it converts any binary data into a sequence of printable ASCII characters that can travel through text-only systems without being misinterpreted or modified.

The same problem appears in other contexts. JSON does not natively support binary data, so binary values like cryptographic keys, file contents, or image data must be encoded as strings to be included in a JSON payload. XML has the same limitation. HTTP headers have restrictions on which characters they can contain. Base64 solves all of these by providing a reliable, universally supported way to represent binary data as a string of safe printable characters.

Where developers actually encounter Base64

JWT tokens are probably the most common place developers run into Base64 in daily work. A JSON Web Token consists of three Base64URL-encoded sections separated by dots: the header, the payload, and the signature. Decoding the header and payload sections reveals the token's claims in readable JSON format, which is useful for debugging authentication issues, inspecting what information a token carries, or verifying that a token was issued with the expected parameters. The signature section is binary and does not decode to readable text.

Data URIs use Base64 to embed file contents directly in HTML or CSS without a separate network request. An image encoded as a Base64 data URI looks like "data:image/png;base64,iVBOR..." and can be used directly as the src attribute of an img tag. This technique eliminates the HTTP request that a normally referenced image would require, which can improve performance for small images or icons, though the 33 percent size overhead from Base64 encoding and the inability to cache the image separately from the page mean it is not always the right choice for larger images.

API authentication frequently uses Base64 for transmitting credentials. HTTP Basic Authentication encodes the username and password as a single Base64 string in the Authorization header. The format is username colon password, encoded as Base64, prefixed with "Basic ". This is why decoding the Authorization header value from a Basic Auth request immediately reveals the credentials in plaintext, which is an important reminder that Base64 is not encryption and provides no security on its own.

Email attachments, as mentioned, are encoded in Base64 by the MIME standard. If you have ever looked at the raw source of an email with an attachment, the attachment appears as a long block of Base64 text between MIME boundary markers. Email clients decode this automatically, but knowing where to look and how to decode it manually is useful for debugging email delivery issues or inspecting what a suspicious attachment actually contains.

Cryptographic data including public keys, certificates, and signatures is commonly distributed in PEM format, which is essentially Base64-encoded binary data with header and footer lines identifying the type of content. An SSL certificate, an SSH public key, and a code signing certificate all use this format. The "BEGIN CERTIFICATE" and "END CERTIFICATE" lines you see when working with TLS certificates are the delimiters around Base64-encoded binary certificate data.

Standard Base64 versus URL-safe Base64

Standard Base64 uses the plus sign and forward slash as two of its 64 characters. Both of these have special meanings in URLs: the plus sign represents a space in URL-encoded form data, and the forward slash is a path separator. When Base64 data needs to appear in a URL, query string, or filename, standard Base64 can cause parsing errors or unexpected behavior because these characters get interpreted rather than treated as literal data.

URL-safe Base64, also called Base64URL and defined in RFC 4648, replaces the plus sign with a hyphen and the forward slash with an underscore. These characters are safe in URLs without percent-encoding and do not have conflicting meanings as path or query separators. URL-safe Base64 also typically omits the trailing equals sign padding, since the padding characters can also cause issues in some URL contexts.

JWT tokens specifically use URL-safe Base64 because they are frequently transmitted in URL query parameters, cookies, and HTTP headers where standard Base64 characters would be problematic. If you are decoding a JWT and getting an error using standard Base64 decoding, switching to URL-safe mode and adding padding back before decoding is usually the fix.

Base64 is encoding, not encryption

This point cannot be overstated: Base64 provides zero security. Any Base64-encoded string can be decoded instantly by anyone who has it, with no key, no password, and no special knowledge beyond the fact that it is Base64. The encoding is completely reversible and publicly specified.

The confusion arises because Base64 strings look like scrambled, unreadable data to anyone who does not know what they are looking at. This visual obscurity is sometimes mistaken for some kind of protection. It is not. A developer who stores passwords in Base64 rather than hashing them has made a serious security mistake. A system that transmits API keys over HTTP because they are Base64-encoded rather than plaintext has not added any security. Anyone who intercepts the data can decode it with a single tool call.

The appropriate use of Base64 is for format compatibility, not for hiding data. If data needs to be secret, encrypt it using an appropriate encryption algorithm before encoding it in Base64. The Base64 encoding can then handle the transport safely, but the security comes from the encryption, not the encoding.

How to identify Base64 encoded data

Base64 strings have a recognizable visual pattern that makes them relatively easy to spot. They consist only of letters, digits, plus signs, and forward slashes in standard Base64, or hyphens and underscores in URL-safe Base64. They often end with one or two equals signs. The length of a Base64 string is always a multiple of 4 in padded form.

A practical test is to try decoding a string that looks like it might be Base64 and see whether the output is readable text or meaningful binary data. If the string is valid Base64 and the decoded result is coherent, it probably is Base64. If the result is garbage, the string either is not Base64 or contains binary data rather than text. This tool makes that test straightforward: paste the candidate string in decode mode and the result is immediate. If you also need to check the decoded output for word or character count, the word counter handles that in one step.

Common errors when working with Base64

Invalid padding is the most common Base64 error. Standard Base64 requires the encoded string length to be a multiple of 4, with equals signs added as padding to reach the next multiple of 4 if needed. Many encoders produce padding correctly, but some systems strip the padding before storing or transmitting the data, and the decoder then fails because the string length is not a multiple of 4. This tool automatically adds back the missing padding before decoding, which handles this case transparently.

Mixing URL-safe and standard Base64 is another frequent source of errors. A JWT decoder that expects URL-safe Base64 will fail on standard Base64 characters, and a standard decoder will fail on URL-safe characters. The URL-safe mode toggle on this tool lets you switch between the two so you can try both if the initial decode fails.

Character encoding issues arise when the original text contains non-ASCII characters, such as emoji, accented letters, or characters from non-Latin scripts. This tool handles the UTF-8 encoding step correctly before Base64-encoding, which is necessary for non-ASCII text to encode and decode correctly. Implementations that assume ASCII-only input will produce incorrect results for anything outside the ASCII range.

Frequently asked questions