Base64 What It Is, What It Isn’t, and When to Actually Use It

If you have spent any time looking at HTTP headers, JWT tokens, or email source code, you have run into Base64. It is everywhere — and it is also frequently misunderstood. People treat it as a light form of encryption, or assume it compresses data, or are not quite sure what it does but know it is “something with encoding.” This article cuts through the confusion.

What Base64 Actually Does

Base64 is an encoding scheme that converts binary data into a string of printable ASCII characters. That is the whole job. Nothing more, nothing less.

Here is the mechanics: Base64 takes every 3 bytes of input data (24 bits) and splits them into four 6-bit groups. Each 6-bit group maps to one of 64 characters from this alphabet:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

If the input length is not divisible by 3, the output is padded with one or two = characters to make it a multiple of 4.

For example, the string Man (3 bytes) encodes to TWFu (4 characters). The string Ma (2 bytes) encodes to TWE=. The string M (1 byte) encodes to TQ==.

You can verify this yourself with the Encoder le texte en Base64 tool — paste any text and see the output immediately.

Why Base64 Exists

Base64 did not appear because someone wanted to obfuscate data. It appeared because of a practical problem: many protocols that move data around the internet were designed to handle text only, and binary data would get corrupted in transit.

SMTP (email) is the classic example. The original SMTP spec treated email bodies as 7-bit ASCII text. If you tried to attach a JPEG — raw binary — the bytes would get mangled by mail servers that stripped the high bit, or interpreted certain byte sequences as control characters. The solution: encode the binary data as printable ASCII before sending, decode it on the other end. That is MIME encoding, and Base64 is the standard method it uses.

The same problem applies to XML documents, JSON payloads, and HTTP headers. These formats expect text. If you want to embed an image in a JSON API response, you cannot just dump raw bytes into a string field. Encode it as Base64 first, and the JSON stays valid.

The Size Overhead

Base64 output is always larger than the input — roughly 33% larger. The math is straightforward: 3 bytes become 4 characters, so the ratio is 4/3 ≈ 1.333.

A 1 MB image encoded in Base64 becomes roughly 1.37 MB of text. This matters when you are deciding whether to embed assets in-line or serve them separately. For small icons or thumbnails, the overhead is acceptable. For large images or file downloads, you are adding unnecessary weight.

Base64 is not compression. It does the opposite. Do not reach for it when you want smaller data — reach for gzip or zstd for that.

What Base64 Is NOT

This is where the real confusion lives.

Not Encryption

Base64 is trivially reversible. Anyone who sees a Base64 string can decode it in seconds using any standard library, or with a tool like Décodage Base64. There is no key, no secret, no algorithm complexity standing in the way. If you see something that “looks encoded” on a JWT, that is intentional — JWTs are not encrypted by default, they are signed. The payload is readable by anyone.

People confuse Base64 with encryption probably because the output looks like noise — a wall of alphanumeric characters that does not resemble the original data. But that similarity ends there. Encryption uses a key and a cipher. Base64 uses a lookup table.

Not Hashing

A hash is a one-way function. You cannot reconstruct the original input from a SHA-256 hash. Base64 is two-way — every encoded string has exactly one original input, and recovering that input requires nothing more than calling a decode function.

Not Compression

Already covered this above, but it bears repeating: Base64 makes data bigger. If someone tells you to Base64-encode data to reduce its size, they are wrong.

Real Use Cases

URI de données

You can embed images directly in HTML or CSS without a separate HTTP request by using a data URI:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..." />

The browser decodes the Base64 data and renders the image without making a network request. This is useful for small icons, loading spinners, or SVG images that need to be self-contained. The Data URI Scheme Generator can build these for you, and the Aperçu et décodeur d'image Base64 lets you paste a data URI and see what image is inside it.

Email Attachments (MIME)

When you attach a file to an email, your email client Base64-encodes the binary content and wraps it in MIME headers. The receiving server and client decode it back. This is handled transparently, but if you have ever looked at raw email source, you will see blocks like:

Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8U
HRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL...

Basic Auth Headers

HTTP Basic Authentication encodes credentials as Base64 in the Authorization header:

Authorization: Basic dXNlcjpwYXNzd29yZA==

That Base64 string decodes to user:password. This is why Basic Auth over plain HTTP is completely insecure — the credentials are trivially recoverable from the header. Over HTTPS, the header is encrypted by TLS, so it is acceptable, but you are still trusting TLS entirely for protection.

Embedding Files in JSON API Responses

When an API needs to return binary data — a generated PDF, a thumbnail, a small audio clip — Base64 encoding lets you include it directly in a JSON field without breaking the JSON structure. The Encoder le fichier en Base64 tool handles this for any file type.

JWT

A JSON Web Token consists of three parts separated by dots. Each part is Base64-URL encoded (a variant described below). The header and payload are just JSON objects — readable by anyone. The signature verifies that the token was not tampered with, but it does not hide the contents. Never store sensitive information in a JWT payload expecting it to be hidden.

Base64 URL-Safe Variant

Base64 standard utilise + et / characters, both of which have special meaning in URLs. When you need to use Base64 in a URL — query string, path segment, cookie value — you use the URL-safe variant:

• + is replaced with -
• / is replaced with _
• = padding is typically omitted

This is what JWTs use. It is also what you will see in URL-safe tokens, signed cookies, and OAuth state parameters. When you are decoding a JWT manually, you need to add padding back before decoding: if the string length modulo 4 is 2, add ==; if it is 3, add =.

# Python: decode a URL-safe Base64 string with padding restoration
import base64

def decode_base64url(s):
    padding = 4 - len(s) % 4
    if padding != 4:
        s += '=' * padding
    return base64.urlsafe_b64decode(s)

When NOT to Use Base64

Do Not Base64-Encode Passwords Before Hashing

A surprisingly common mistake: developers Base64-encode a password before passing it to bcrypt or Argon2, thinking it adds security. It does not. Base64 is reversible, so the “pre-hashed” value is just as sensitive as the original password. Worse, some password hashing libraries truncate input at 72 bytes (bcrypt does this), and Base64 encoding expands the input, potentially causing long passwords to produce the same hash.

Do Not Use It as Obfuscation

Security through obscurity is not security. If you Base64-encode an API key, a license string, or any other sensitive value in client-side code, it takes a junior developer about 30 seconds to decode it. Treat Base64 as plaintext — because anyone who can see it can read it.

Do Not Encode Large Files in API Responses

For anything beyond a few hundred kilobytes, Base64 encoding in a JSON response is the wrong approach. The 33% overhead compounds with JSON parsing overhead, memory usage, and transfer time. Use a proper file upload/download endpoint — accept multipart form data for uploads, return a direct URL or binary stream for downloads. Reserve Base64 for small, convenience cases where an extra HTTP round-trip costs more than the encoding overhead.

Recognizing Base64 in the Wild

Base64 strings have a recognizable pattern:

• Only characters from [A-Za-z0-9+/=] (ou [A-Za-z0-9-_] for URL-safe)
• Length is always a multiple of 4 (in standard form with padding)
• Ends with 0, 1, or 2 = , pas 255 octets — mais la limite de stockage d'une seule ligne est calculée en octets. Avec
• Has no spaces or punctuation other than +, /et =

If you spot a suspicious-looking string in a header, a cookie, or a config file, paste it into the Décodage Base64 tool. If it decodes to readable text or a valid binary signature, it is Base64. If it decodes to noise, it is probably actually encrypted or compressed data that happens to look similar.

The distinction matters: Base64 strings in logs or headers can leak information you did not expect to expose. Check what your application is encoding before assuming it is safe to log.

Référence Rapide

• Use Base64 when: you need to pass binary data through a text-only channel (email, JSON, HTML attributes, HTTP headers)
• Do not use Base64 when: you need security, compression, or efficient transfer of large files
• Standard alphabet: A-Z, a-z, 0-9, +, / with = padding
• URL-safe alphabet: A-Z, a-z, 0-9, -, _ without = padding
• Size overhead: ~33% larger than the original
• Reversible: yes, trivially, with no key required

Vous aimerez peut-être aussi