Base64 Encode / Decode

What Base64 Does

Base64 turns arbitrary bytes into a string of printable characters. That is the entire purpose. Wherever a channel can only carry text — an email body, a JSON field, an HTTP header, a URL parameter — binary data has to be represented in characters that the channel will not mangle, and Base64 is the standard way to do it.

The cost is size. Three bytes become four characters, so the encoded form is about a third larger than the input. In exchange, the output survives copying, line wrapping, and protocols that would otherwise corrupt raw bytes.

This tool encodes and decodes in both directions, in the browser. Drop text in to encode it, paste a Base64 string in to read it back.

How the Encoding Works

The input is read as a stream of bits and regrouped. Bytes are 8 bits wide; Base64 characters each carry 6 bits. Taking three bytes at a time gives 24 bits, which divides neatly into four 6-bit values. Each 6-bit value indexes into a 64-character alphabet, and four characters come out.

When the input length is not a multiple of three, the last group is short and gets padded. One leftover byte produces two characters and ==; two leftover bytes produce three characters and =. The padding is not data — it exists so decoders can tell how many bits were real.

So "Man" encodes to TWFu, and "Ma" to TWE=. Notice that the first two characters are the same in both, because the first bits are the same; that property is what makes the encoding reversible without any lookup tables beyond the alphabet itself.

Decoding runs the process backwards: strip whitespace and padding, map characters to 6-bit values, concatenate, and cut back into bytes.

Where It Is Used

The pattern is always the same: something binary has to travel through something textual. A few places it shows up constantly:

• Email attachments. MIME encodes files as Base64 so they can sit inside a plain-text message.
• Data URIs. Small images, fonts, and icons are inlined in CSS or HTML as data:image/png;base64,....
• APIs and JSON. Binary payloads such as keys, certificates, or thumbnails are carried in string fields.
• Authentication headers. HTTP Basic authentication sends username:password encoded this way.
• Tokens. JWT segments are Base64url-encoded JSON, separated by dots.
• Key files. PEM certificates wrap Base64 between -----BEGIN----- and -----END----- lines.

None of those uses involve secrecy. Base64 is a transport format, and the fact that a string looks unreadable is a side effect of the alphabet, not a security property.

Using the Tool

Paste your input into the box, pick encode or decode, and the result appears alongside it. Encoding is safe for any text; decoding requires input that is actually Base64, since arbitrary text will usually fail the alphabet check or produce nonsense bytes.

Two practical notes. First, the tool works on text, which the browser converts to bytes using UTF-8 before encoding — so a multi-byte character such as an emoji becomes several bytes and changes the output length. Second, large inputs are processed locally and may take a moment; nothing is uploaded.

If decoding produces garbage, the usual causes are line breaks that were not meant to be there, a URL-safe variant using - and _ instead of + and /, or a string that was truncated.

The Alphabet and Padding

RFC 4648 defines the standard alphabet as the 26 uppercase letters, the 26 lowercase letters, the ten digits, +, and /. That is exactly 64 symbols. All of them are printable ASCII and none is a control character, which is what makes the output safe for text protocols.

Each symbol maps to a 6-bit value in a fixed order: A is 0, B is 1, and so on through Z at 25; a continues at 26 through z at 51; 0 through 9 cover 52 to 61; + is 62 and / is 63.

Padding keeps the output length a multiple of four. A single trailing byte leaves 8 bits, which become two 6-bit symbols with four bits left over, so two = characters are appended. Two trailing bytes leave 16 bits, giving three symbols and six spare bits, so one = is appended. Strict decoders require the padding; lenient ones infer it from the length.

Compared With Other Encodings

Several schemes solve the same problem with different trade-offs between size and safety.

Hex (base16) uses 16 symbols and doubles the length of the data. It is trivially readable and easy to implement, which is why hashes and byte dumps are usually shown in hex. For raw byte counts, though, it is the least efficient of the common options. The Hex Calculator covers arithmetic in that base.

Base32 uses 32 symbols, typically A–Z plus 2–7, and adds 60% overhead. It is case-insensitive and avoids ambiguous characters, which makes it suitable for secrets that people read aloud or type by hand, such as one-time password seeds.

Base64 adds 33% overhead and is the default choice when a machine, not a person, will read the result.

Base85 / ASCII85 adds about 25% and appears in PostScript and PDF. It is more compact and considerably harder to implement and inspect, which is why it stayed niche.

Percent-encoding is a different idea entirely. It does not encode binary for transport; it escapes reserved characters inside a URL. The URL Encode/Decode tool handles that job.

Data URIs in Web Pages

A data URI embeds the resource in the document instead of pointing at it:

data:[mime-type];base64,[base64-data]

A small PNG therefore looks like data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA... and can be used directly in an img tag or a CSS url().

The benefit is one fewer request, which mattered a great deal before HTTP/2 and still matters on high-latency connections. The costs are real too: the asset grows by a third, it cannot be cached separately from the document that contains it, and it delays the first paint because the HTML or CSS is larger. Inlining also defeats compression on the image data, since the bytes are already encoded.

As a rule, inlining pays for very small assets — an icon, a spacer, a tiny font subset — and loses for anything of consequence. It is also worth remembering that a data URI is rendered by the browser with the privileges of the page, so untrusted data should never be inlined into srcdoc or an SVG context.

Email and MIME

SMTP was designed for seven-bit text. Sending an attachment through it requires the file to be represented as characters, and MIME does exactly that with Base64.

Two details distinguish MIME's use from the plain form. Lines are wrapped at 76 characters with CRLF endings, because old mail transport imposed line-length limits, and each part of a multipart message carries headers describing its content type and transfer encoding. The encoded body is preceded by Content-Transfer-Encoding: base64.

This is why email attachments are about a third larger than the files they carry, and why a message with several images can exceed a mailbox limit faster than expected. It also explains the occasional = at the end of a line in raw message source: that is padding at the end of the encoded body, not part of the file.

Base64 Is Not Encryption

The most common misunderstanding about Base64 is that it hides information. It does not. Anyone with the encoded string and a decoder — which is every browser and every programming language — gets the original back. There is no key and no secret.

Encoding is reversible by design, and that is the point: the receiver has to be able to recover the data. Encryption is different in kind. It uses a key, and without that key the ciphertext should be unrecoverable.

The confusion has real consequences. Credentials embedded in a data URI, a configuration file, or an authentication header are not protected by being encoded; they are merely less obvious at a glance. Treat any Base64 blob as public unless the channel itself is secured.

If you need confidentiality, use TLS in transit and a proper encryption scheme at rest — AES-GCM or ChaCha20-Poly1305 — with keys managed separately from the data. If you need integrity, a signature or MAC is the tool. Base64 supplies neither.

Encoding Different Kinds of Data

Base64 itself does not know or care what the bytes represent. What varies is how you get bytes in the first place and how you interpret them on the way out.

Text. A string is converted to bytes using a character encoding, normally UTF-8. This is why the same word in different encodings produces different Base64: the underlying bytes differ. Decoding without knowing the original encoding is guesswork.

Images and other binary files. The file is read byte for byte, with no interpretation. The MIME type is not stored in the Base64 — it has to travel alongside, as it does in a data URI or a MIME part.

Compressed data. Compress first, then encode. The order cannot be reversed, because Base64 output compresses poorly.

Numbers and structures. Serialize to JSON or a binary format, then encode the result. Encoding a number's decimal representation is a common source of mismatches between systems expecting a byte-level representation.

Common Mistakes

Treating it as security. Covered above, and still the most damaging error. Encoded is not encrypted.

Mixing alphabets. The standard alphabet uses + and /; the URL-safe variant uses - and _. Decoding one with a decoder expecting the other fails or silently corrupts. JWT and many APIs use the URL-safe form.

Losing padding. Some systems strip = characters. Strict decoders reject the result; lenient ones accept it. If a string decodes in one tool and not another, check the padding first.

Wrapping lines unexpectedly. Whitespace inside an encoded string is usually tolerated, but a line break inserted in the middle of a token can break systems that treat the whole string as opaque.

Encoding after compression in the wrong order. Compress, then encode. Encoding first makes the data incompressible.

Forgetting the size increase. A 33% expansion on a large payload can exceed a header or field limit that the raw data would have fit inside.

Assuming the MIME type survives. It does not. The type must be transmitted separately.

Variants: URL-Safe and Others

The standard alphabet contains + and /, both of which have meaning inside a URL. Putting a standard Base64 string in a query parameter or a path segment therefore requires percent-encoding it, which adds another layer of expansion.

Base64url, defined in the same RFC, solves this by substituting - for + and _ for /, and often omitting padding. It is the variant behind JWT, JWK, and many API tokens.

Other variants exist for historical reasons. The MIME form uses the standard alphabet with 76-character lines. Some older implementations used different alphabets entirely, which is why a string that looks like Base64 sometimes decodes to nonsense — it may be a different base64 dialect.

When exchanging data between systems, the safe approach is to state the variant explicitly rather than assume the default.

Performance and Size

The 33% expansion is the obvious cost. Three bytes in, four characters out, so a 1 MB file becomes roughly 1.37 MB of text. Over a network that is bandwidth; in memory it is allocation.

There is also CPU work on both ends: encoding walks the input in 3-byte groups and does bit shifting, decoding reverses it. Modern hardware handles this quickly, and in most applications it is not the bottleneck. Where it does matter is high-throughput paths — logging binary payloads, encoding every response, or processing large uploads in memory.

Two rules follow. Do not encode data that the transport can already carry as bytes; the expansion buys nothing. And do not base64 large blobs into JSON when a separate binary endpoint or multipart upload would do.

Streaming encoders exist for files that are too large to hold in memory: they process the input in chunks, carrying over the one or two leftover bytes between chunks so the boundaries stay aligned.

Summary

Base64 maps bytes onto 64 printable characters so that binary data can cross text-only channels unharmed. It expands the payload by a third, requires padding to keep lengths aligned, and is trivially reversible.

Use it for transport, not for secrecy. Choose base64url when the result will live in a URL or a token, and remember that the MIME type, character encoding, and compression state all live outside the encoded string.