Robots Atlas>ROBOTS ATLAS
Data

Base64

2006ActivePublished: 29 September 2026Updated: 29 September 2026Published
Key innovation
A standardized, reversible way to represent arbitrary binary data as ASCII text that is safe to transmit over text-only channels.
Category
Data
Abstraction level
Primitive
Operation level
DataSystemTooling
Use cases
Embedding images and files in data URIs (e.g. in HTML/CSS)Email attachments in the MIME standardEncoding JWT tokens (base64url)Sending images to multimodal AI models via APIsSerializing binary data in JSON and XMLObfuscating prompts in prompt-injection / jailbreak attacks (AI security)Smuggling and exfiltrating data in model inputs/outputs

How it works

Base64 processes input in groups of 3 bytes (24 bits). Each 24-bit group is split into four 6-bit chunks (sextets), and each sextet (value 0โ€“63) is an index into the 64-character encoding alphabet, yielding 4 output characters. When the input length is not a multiple of 3, the final incomplete group is padded with zero bits and the missing output positions are filled with the '=' padding character: 1 input byte yields 2 characters + '==', and 2 bytes yield 3 characters + '='. Decoding reverses the process. The base64url variant uses the same mechanism but with an alphabet where '+' and '/' are replaced by '-' and '_'.

Problem solved

Many protocols and formats (email, JSON, XML, URLs) were designed for text and do not safely carry raw binary bytes โ€” bytes outside the printable ASCII range can be corrupted, truncated, or interpreted as control characters. Base64 solves this by mapping arbitrary binary data onto a safe, printable subset of ASCII, so it can traverse a text channel and be reconstructed exactly.

Components

64-character encoding alphabetMaps 6-bit sextets to output characters

A table mapping values 0โ€“63 onto printable ASCII characters. In the standard variant: Aโ€“Z (0โ€“25), aโ€“z (26โ€“51), 0โ€“9 (52โ€“61), '+' (62), '/' (63).

Standard (base64)Characters 62 and 63 are '+' and '/'. The default variant in MIME and most general-purpose use.
URL-safe (base64url)Characters 62 and 63 are '-' and '_', making the output safe in URLs and filenames. Used e.g. in JWT.

Official

24-bit grouping (3 bytes โ†’ 4 characters)Converts 8-bit units into 6-bit units

Splits the input stream into 24-bit groups and further into four 6-bit sextets.

INThree bytes of binary data.
OUTFour characters from the 64-character alphabet.
Padding ('=')Signals the number of significant bytes in the final group

Mechanism for handling incomplete groups at the end of the input: 1 byte โ†’ 2 characters + '==', 2 bytes โ†’ 3 characters + '='. Ensures the output length is a multiple of 4.

Official

Implementation

Implementation pitfalls
Confusing Base64 with encryptionCritical

Base64 is fully reversible without a key and provides no confidentiality. In AI contexts this cuts both ways: sensitive data encoded in Base64 stays exposed, and content filters that inspect only plaintext may miss malicious instructions encoded in Base64 (prompt-injection/jailbreak).

Fix:Treat Base64 purely as transport, not as protection. Decode and sanitize content before filtering, and use real encryption for confidentiality.
Confusing standard vs base64urlHigh

Using the standard alphabet ('+','/') where base64url ('-','_') is required breaks URLs, filenames, and JWT tokens.

Fix:Match the variant to the context and explicitly select url-safe functions when working with URLs/JWT.
Fragile handling of padding and whitespaceMedium

Libraries differ in how they treat missing '=' and whitespace/line breaks, causing decode errors across systems.

Fix:Normalize input (strip whitespace, restore padding) or use lenient modes per the specification.
Ignoring the ~33% size overheadMedium

Encoding grows size by about 1/3, which for large images/files in multimodal prompts increases token, bandwidth, and cost usage.

Fix:Account for the overhead in token and size limits; consider compressing data before encoding.

Evolution

Original paper ยท 2006 ยท IETF RFC 4648 ยท Simon Josefsson
RFC 4648: The Base16, Base32, and Base64 Data Encodings
Simon Josefsson
1993
Privacy-Enhanced Mail (RFC 1421)

One of the early standardized uses of Base64 encoding to carry binary data in email.

1996
MIME standardizes Base64 (RFC 2045)
Inflection point

Base64 became one of MIME's Content-Transfer-Encodings, popularizing it as the way to encode email attachments.

2003
RFC 3548 โ€” first standalone specification

The first specification collecting Base16/Base32/Base64 into a single document independent of MIME.

2006
RFC 4648 โ€” the current standard
Inflection point

Obsoleted RFC 3548, reconciled implementation discrepancies, and formalized the URL-safe (base64url) variant.

2015
JWT (RFC 7519) popularizes base64url

JSON Web Token based the encoding of its header, payload, and signature on base64url, making the variant ubiquitous in web and API authentication.

Hyperparameters (configurable axes)

Alphabet variantHigh

Standard ('+','/') vs URL-safe ('-','_').

standardMIME and general-purpose use
base64urlURLs, filenames, JWT
Padding '='Medium

Whether to append '=' padding characters. Some profiles (e.g. certain base64url uses) omit padding.

with paddingMatches the RFC 4648 default
no paddingCommon in web tokens
Line wrappingLow

Optional splitting of output into lines (e.g. 76 characters in MIME) for email compatibility.

no wrappingDefault in RFC 4648
76 chars/lineMIME (RFC 2045)

Computational complexity

Time complexity: O(n). Space complexity: O(n).

Parallelism

Parallelism level
Fully parallel

Each 24-bit group (3 bytes) is encoded independently of the others, so encoding/decoding is trivially parallelizable across blocks.

Hardware requirements

Primary

Base64 requires only simple bitwise operations and table lookups available on any CPU; it needs no accelerators.