Base64 là gì? Khi nào nên dùng (và khi nào đừng)【2026】
Base64 = cách viết lại binary thành text ASCII an toàn cho kênh chỉ nhận chữ — không phải khóa bảo mật. Dùng khi JSON/header/email không nuốt được byte thô. Tránh khi cần giấu secret, khi file lớn (phình ~33%), hoặc khi đã có URL/multipart. Hiểu đúng khái niệm trước khi encode hàng loạt — thử nhanh trên công cụ Base64 Kawa (chạy trong trình duyệt, không cần đăng ký).
Bạn thấy chuỗi SGVsbG8= trong tài liệu API, hoặc đồng nghiệp bảo “cứ Base64 cái ảnh rồi nhét vào JSON”. Nhiều intern / fresher ở team outsourcing Việt Nam nhầm Base64 = mã hóa — gửi Authorization: Basic với mật khẩu “đã Base64” rồi tưởng an toàn. Bài này tập trung khái niệm và quyết định dùng / không dùng, không đi sâu Data URI payload (đã có bài riêng) cũng không đi sâu lỗi dấu tiếng Việt khi decode.
Ai nên đọc
- Sinh viên / fresher mới gặp từ “Base64” trong RFC hoặc Postman
- Backend / fullstack viết API nhận binary trong JSON
- Ai đang cân nhắc “giấu” token bằng Base64 trong config
- Reviewer muốn checklist ngắn trước khi approve PR nhúng Base64
Base64 là gì?
Base64 là thuật toán encoding (biến đổi biểu diễn), không phải encryption. Nó lấy dãy byte bất kỳ và viết lại bằng 64 ký tự in được:
A–Z (26)
a–z (26)
0–9 (10)
+ / (2)
= (padding, không thuộc "64" nhưng luôn gặp)Cơ chế gọn: lấy 3 byte = 24 bit, chia thành 4 nhóm 6 bit, mỗi nhóm map sang 1 ký tự trong bảng 64. Vì vậy tên “Base64” — 2^6 = 64.
Ví dụ tối thiểu:
"Hi" → bytes 48 69 → SGk=
"Hello" → SGVsbG8=Bạn có thể encode/decode ngay trên Base64 Encode/Decode để đối chiếu kết quả với tài liệu API.
Encoding ≠ encryption ≠ hashing
| Kỹ thuật | Đảo ngược? | Mục đích |
|---|---|---|
| Base64 encode | Có — ai cũng decode | Binary → text an toàn trên kênh ASCII |
| Encryption (AES…) | Có — chỉ ai có key | Bảo mật nội dung |
| Hash (SHA-256…) | Không (một chiều) | Checksum / chữ ký / fingerprint |
Nếu PR ghi “encrypt password bằng Base64” — đó là lỗi kiến trúc, không phải chi tiết syntax.
Tại sao cần Base64?
Nhiều hệ thống không an toàn với byte tùy ý:
- JSON là text — không nhét raw PNG vào giữa dấu ngoặc kép
- HTTP header (Basic Auth) kỳ vọng ASCII
- Email MIME truyền đính kèm dưới dạng text-safe
- Log / clipboard / chat dễ làm hỏng null byte hoặc ký tự điều khiển
Base64 đổi binary thành chuỗi chỉ gồm chữ cái, số, +, /, = — gần như luôn sống sót qua copy-paste và JSON.parse.
Giá phải trả: kích thước tăng khoảng 33%, và chuỗi không đọc được bằng mắt (dù decode cực dễ).
Khi nào nên dùng
| Tình huống | Ví dụ | Ghi chú |
|---|---|---|
| Basic Auth | Authorization: Basic + Base64(user:pass) | Vẫn gửi qua TLS — Base64 không thay HTTPS |
| Payload JSON nhỏ | Chữ ký, thumbnail vài KB, certificate PEM đã encode | Giữ payload nhỏ; ưu tiên multipart nếu lớn |
| Email / MIME | Đính kèm trong message | Chuẩn ngành; client tự decode |
| Debug / học | Đọc chuỗi lạ trong log | Decode local, che PII trước khi paste tool lạ |
| Config text-only | Một số hệ thống chỉ lưu string | Vẫn không phải nơi cất secret production |
Ví dụ Basic Auth (đúng kỳ vọng)
Authorization: Basic dXNlcjpwYXNzỞ đây dXNlcjpwYXNz chỉ là user:pass đã encode. Ai bắt được header (không có TLS) đều đọc được ngay. Base64 ở đây là định dạng bắt buộc của RFC, không phải lớp bảo mật.
Ví dụ JSON chứa binary nhỏ
{
"filename": "stamp.png",
"contentBase64": "iVBORw0KGgoAAAANSUhEUgAAAAEAAAAB..."
}Hợp lý với stamp/icon rất nhỏ. Với ảnh 2MB — hãy upload file hoặc pre-signed URL, đừng Base64 cả object.
Khi nào không nên dùng
- Che mật khẩu / API key / token production — decode 1 click là lộ.
- File lớn trong HTML/CSS/JSON — phình ~33%, chậm mobile 3G/4G, khó cache (chi tiết Data URI xem bài riêng).
- Thay thế hash — Base64 không chứng minh toàn vẹn như SHA-256.
- Thay thế HTTPS — encode rồi gửi HTTP plain vẫn bị nghe lén dễ dàng.
- Lưu trữ dài hạn thay blob storage — database text phình, index kém, migration đau.
“Đã Base64 rồi nên commit vào Git được” — sai. Secret trong repo vẫn là secret. Dùng biến môi trường, secret manager, hoặc vault — không dựa vào encoding.
Padding = và độ dài chuỗi
| Byte gốc (mod 3) | Padding | Độ dài output (mod 4) |
|---|---|---|
| 0 | không có = | chia hết 4 |
| 1 | == | chia hết 4 |
| 2 | = | chia hết 4 |
Cắt mất = khi copy từ PDF/Slack, hoặc thêm khoảng trắng/xuống dòng vào giữa chuỗi, là nguồn lỗi Invalid character / Failed to execute 'atob' rất thường gặp.
URL-safe / Base64URL: +→-, /→_, thường bỏ padding. JWT dùng biến thể này — đừng decode segment JWT bằng alphabet chuẩn rồi trách “token hỏng”.
Checklist quyết định (in ra dán cạnh màn hình)
Trước khi thêm Base64 vào PR, trả lời:
- Kênh truyền bắt buộc text? (Nếu có binary upload → khỏi Base64)
- Kích thước sau ×4/3 còn chấp nhận được trên mobile / quota API?
- Có ai hiểu nhầm đây là encryption không? (ghi chú trong code review)
- Đã chọn đúng chuẩn vs URL-safe theo spec?
- Secret có bị encode rồi commit / log không?
Nếu 1–2 câu trả lời “không chắc” — encode thử 1 mẫu trên công cụ Base64 (có tùy chọn URL Safe, xử lý local) rồi đối chiếu với fixture của đối tác.
Case study ngắn
1) Fresher “mã hóa” API key bằng Base64 trong .env.example
Team review thấy API_KEY=c2stcHJvZC0uLi4= và tưởng đã an toàn để public. Decode ra plaintext. Sửa: xóa key, rotate, đưa vào secret store; .env.example chỉ để placeholder.
2) Mobile app nhét ảnh hóa đơn 1.5MB vào JSON Base64
Request timeout trên mạng Viettel/Vina chậm buổi tối; body ~2MB. Sửa: upload multipart hoặc pre-signed URL, JSON chỉ giữ fileId.
Liên quan (đọc tiếp theo nhu cầu)
- Cần encode/decode hàng ngày (clipboard, đoạn JWT, file nhỏ) → Encode/decode Base64 thao tác thực tế
- Cân nhắc nhúng ảnh/font Data URI → Data URI Base64: khi nào nên / tránh
- Chữ Việt bị lỗi dấu sau decode → bài UTF-8 / decode tiếng Việt (nếu có trên site)
- Thử tay không upload: Base64 tool