Base64 Encoding Explained — JWT Tokens, Data URIs, and Kubernetes Secrets

Base64 编码详解：JWT Token、Data URI 与 Kubernetes Secrets

You have probably copied a Base64 string a hundred times without thinking about it. That long chain of letters and slashes at the end of a JWT. The data:image/png;base64, blob in a CSS file. The Authorization: Basic header in a Postman collection. Base64 is everywhere in a developer’s daily work — and most developers have a fuzzy mental model of what it actually does. This article clears that up, and covers the five real production use cases where you will encounter it.

你可能已经复制过无数次 Base64 字符串，却从未深究过它。比如 JWT 末尾那串长长的字母和斜杠，CSS 文件中的 data:image/png;base64, 数据块，或是 Postman 集合中的 Authorization: Basic 请求头。Base64 在开发者的日常工作中无处不在，但大多数开发者对它的实际原理只有模糊的认知。本文将为你理清这些概念，并涵盖你在生产环境中会遇到的五个真实应用场景。

What is Base64 and why does it exist?

什么是 Base64，它为何存在？

Base64 converts binary data into a string of 64 printable ASCII characters: the letters A–Z and a–z, digits 0–9, plus + and /. The name literally describes the alphabet size. The reason it exists: many systems that move data were designed for text only. Email protocols (SMTP), HTML attributes, JSON payloads, XML documents, HTTP headers — all of these were built around the assumption that data is readable ASCII text. Raw binary bytes can corrupt or break these systems. Base64 solves this by guaranteeing that whatever you encode will contain only characters that transmit safely through any text-based system.

Base64 将二进制数据转换为由 64 个可打印 ASCII 字符组成的字符串：包括 A–Z、a–z、0–9，以及 + 和 /。其名称直接反映了字符集的大小。它存在的原因是：许多数据传输系统最初仅为文本设计。电子邮件协议 (SMTP)、HTML 属性、JSON 载荷、XML 文档、HTTP 请求头——所有这些都基于“数据是可读 ASCII 文本”的假设。原始的二进制字节可能会损坏或破坏这些系统。Base64 通过确保编码后的内容仅包含能在任何基于文本的系统中安全传输的字符，从而解决了这一问题。

The size tradeoff

大小权衡

Base64 encodes every 3 bytes of input into 4 output characters. That means encoded output is always approximately 33% larger than the original data. This is the price of universality. The = or == at the end of a Base64 string is padding — added when the input length is not divisible by 3. One = means one byte of padding was needed; == means two bytes. Never strip padding manually — it is part of the RFC 4648 standard and removing it breaks decoding.

Base64 将每 3 个字节的输入编码为 4 个输出字符。这意味着编码后的输出总是比原始数据大 33% 左右。这是为了通用性所付出的代价。Base64 字符串末尾的 = 或 == 是填充符，当输入长度不能被 3 整除时添加。一个 = 表示需要一个字节的填充；== 表示需要两个字节。切勿手动删除填充——它是 RFC 4648 标准的一部分，删除它会导致解码失败。

Base64 is NOT encryption

Base64 不是加密

This is the most important thing to understand, and it gets confused constantly. Base64 is encoding, not encryption. Anyone can decode it instantly with zero key or password. There is nothing protecting the data — it is just a different representation.

这是最重要的一点，也是最容易被混淆的地方。Base64 是编码，而非加密。任何人都可以无需密钥或密码瞬间将其解码。它没有任何保护数据的作用——它仅仅是数据的另一种表现形式。

// This is NOT secure
const secret = btoa("admin:password123"); 
// Result: YWRtaW46cGFzc3dvcmQxMjM= 
// Anyone can run atob("YWRtaW46cGFzc3dvcmQxMjM=") and read it

Never store passwords, API secrets, or private tokens as Base64 and assume they are secure. Use proper encryption (AES-256, bcrypt, Argon2) when you need actual protection.

永远不要将密码、API 密钥或私有 Token 仅以 Base64 形式存储并认为它们是安全的。当你需要真正的保护时，请使用适当的加密算法（如 AES-256、bcrypt、Argon2）。

The 5 places you will encounter Base64 in production

你在生产环境中会遇到的 5 个场景

1. JWT Tokens

1. JWT Token

A JWT (JSON Web Token) has three Base64URL-encoded parts separated by dots: header.payload.signature. The header and payload are Base64URL encoded — not standard Base64. Base64URL is a URL-safe variant that replaces + with - and / with _ to avoid issues in URLs and HTTP headers.

JWT (JSON Web Token) 由三个通过点号分隔的 Base64URL 编码部分组成：header.payload.signature。Header 和 Payload 使用的是 Base64URL 编码，而非标准 Base64。Base64URL 是一种 URL 安全变体，它将 + 替换为 -，将 / 替换为 _，以避免在 URL 和 HTTP 请求头中出现问题。

Note: Never verify a JWT by just decoding the payload. Always verify the signature server-side. Client-side JWT decoding is fine for reading claims (user ID, role, expiry) — but never trust unverified claims for authorization decisions.

注意：永远不要仅通过解码 Payload 来验证 JWT。务必在服务端验证签名。客户端解码 JWT 仅适用于读取声明（用户 ID、角色、过期时间）——但切勿信任未经校验的声明来进行授权决策。

2. HTTP Basic Authentication

2. HTTP 基本认证

HTTP Basic Auth sends credentials in the Authorization header as Base64-encoded username:password: Authorization: Basic YWRtaW46cGFzc3dvcmQxMjM= (Decoded: admin:password123)

HTTP 基本认证通过 Authorization 请求头发送以 Base64 编码的 username:password： Authorization: Basic YWRtaW46cGFzc3dvcmQxMjM=（解码后为：admin:password123）

3. Data URIs — Embedding Images in HTML and CSS

3. Data URI — 在 HTML 和 CSS 中嵌入图片

A data URI lets you embed a file directly into HTML or CSS without a separate HTTP request. The format is: data:[media type];base64,[Base64 encoded data].

Data URI 允许你将文件直接嵌入 HTML 或 CSS 中，而无需发起额外的 HTTP 请求。格式为：data:[媒体类型];base64,[Base64 编码数据]。

When to use: Small icons (under 2–3 KB), email templates, or Canvas-generated images.
When NOT to use: Images over ~5 KB (size overhead), images used on multiple pages (cannot be cached), or lazy-loaded content.
适用场景： 小图标（2–3 KB 以下）、邮件模板或 Canvas 生成的图片。
不适用场景： 超过 5 KB 的图片（体积开销大）、多页面共用的图片（无法单独缓存）或懒加载内容。

4. Kubernetes Secrets

Every value in a Kubernetes Secret manifest must be Base64-encoded. This is a common point of confusion for developers new to Kubernetes — it looks like the credentials are protected, but Base64 is just encoding, not encryption. Kubernetes Secrets are not inherently secure; you need additional tooling (Sealed Secrets, HashiCorp Vault, AWS Secrets Manager) for real secret management.

Kubernetes Secret 清单中的每个值都必须进行 Base64 编码。这对 Kubernetes 新手来说是一个常见的困惑点——看起来凭据似乎受到了保护，但 Base64 只是编码而非加密。Kubernetes Secrets 本身并不安全；你需要额外的工具（如 Sealed Secrets、HashiCorp Vault、AWS Secrets Manager）来进行真正的密钥管理。