What Is Base64? Encoding, Decoding and Common Uses

Text is a representation of bytes, not their meaning

A file can contain bytes that do not correspond to readable characters, or characters that have a special role in a transport format. Base64 maps byte groups into a limited alphabet so those bytes can be represented as ordinary text. The receiving system still needs to know what the decoded bytes represent: an image, document, text string or something else.

For a text string, character encoding comes first. UTF-8, for example, turns characters into bytes; Base64 then represents those bytes as text. Decoding in the reverse order gives bytes that can be interpreted as UTF-8. Treating a multi-byte character as though it were a single ASCII byte can corrupt the result.

Three input bytes become four encoded characters

Three bytes contain 24 bits. Base64 groups those bits into four groups of six bits, using each group to select a character from an alphabet of 64 possibilities. The familiar alphabet contains uppercase and lowercase letters, digits, + and /. The Base64 specification defines the alphabet and padding conventions.

If the final input group has only one or two bytes, the conventional padded representation uses = characters to complete the final four-character group. Padding is not additional file content. Some protocols omit it or specify another convention, so “looks like Base64” is not enough to know which parser rules to apply.

Text: Hello
UTF-8 bytes: 48 65 6c 6c 6f (hexadecimal)
Base64: SGVsbG8=
Decoded UTF-8 text: Hello

Where the representation is useful

Email attachment formats can use Base64 to carry file bytes in a message representation. An API may put a small encoded file in a JSON string when its contract calls for that. A data URL can embed encoded content inside a URL-like string, and a generated document may embed a small asset rather than refer to a separate file.

Those choices come with tradeoffs. Embedding an image can remove a separate request, but enlarges the surrounding text and ties the image’s delivery or caching to that text. A dedicated binary upload or file response may be a better match for larger content. Follow the receiving system’s API or document specification instead of encoding every file by default.

data:text/plain;base64,SGVsbG8=

The prefix here declares a text/plain media type and Base64 representation. Other data URLs can contain different media types. Do not treat an arbitrary decoded payload as safe to open or execute just because its encoding was valid.

The size overhead is predictable before packaging

For n input bytes, padded Base64 uses 4 × ceil(n ÷ 3) characters. For large inputs, that is approximately one third more characters than the original byte count. Small inputs can have a much larger percentage increase because the final group still occupies four characters.

A data URL prefix, JSON property name, quotation marks or email line wrapping adds more text. Conversely, transport compression can affect the final number of transferred bytes. Keep the raw encoding estimate separate from the size of the complete message on disk or on the network.

Ordinary Base64 and Base64URL are related but different

Base64URL substitutes - and _ for + and /, making its alphabet convenient in URL-oriented contexts. Its padding rules depend on the surrounding protocol. A decoder expecting ordinary padded Base64 may reject a URL-safe string unless it explicitly supports that variant.

The common signed JWT format uses Base64URL for its readable sections. The JWT guide explains how those sections relate to a signature. Successfully decoding the encoded JSON says nothing about whether that signature is valid or whether an application should trust its claims.

Encoding is not encryption or a security boundary

When debugging, identify the expected variant, byte encoding and destination format. A decoding error may come from whitespace rules, a truncated value or the wrong alphabet. A successful decode may still produce bytes that are not valid text. Keep the original value while investigating rather than silently replacing undecodable characters.

Use a short synthetic sample for a first test, then inspect only data you are authorized to handle. Copying an encoded secret into a ticket or screenshot still shares that secret in a reversible form. Local processing can reduce a remote-processing step, but does not remove clipboard, device or organizational handling concerns.