Trình giải mã hình ảnh Base64
Dán một chuỗi Base64 để xem trước và tải xuống hình ảnh.
Cách sử dụng
- Dán một chuỗi hình ảnh được mã hóa Base64 vào khu vực nhập. Nó có thể bao gồm tiền tố
data:image/…hoặc chỉ chứa dữ liệu Base64 thô. - Nhấp vào Giải mã hình ảnh để xem trước.
- Nhấp vào Tải xuống hình ảnh để lưu thành tệp PNG.
Câu hỏi thường gặp
Các định dạng Base64 nào được hỗ trợ?
Bạn có thể dán một chuỗi Base64 thô (công cụ tự động phát hiện định dạng) hoặc một URI dữ liệu đầy đủ như data:image/png;base64,iVBOR…. Các loại hình ảnh được hỗ trợ: PNG, JPEG, WebP, GIF, BMP và SVG.
Có giới hạn kích thước không?
Không có giới hạn cứng, nhưng các chuỗi Base64 rất lớn (hơn 5–10 MB) có thể mất thời gian để xử lý tùy thuộc vào thiết bị của bạn.
Cách mã hóa hình ảnh thành Base64?
Sử dụng công cụ Trình Chuyển Đổi Hình Ảnh Sang Base64 của chúng tôi · chỉ cần kéo-thả một hình ảnh để có chuỗi Base64 của nó.
Base64 thực sự là gì
Base64 là một lược đồ mã hóa nhị phân sang văn bản được định nghĩa trong RFC 4648 (tháng 10 năm 2006). Nó dùng bảng chữ cái 64 ký tự, A-Z, a-z, 0-9, cộng với + và /: để biểu diễn byte tùy ý dưới dạng ASCII in được. Cứ mỗi ba byte đầu vào nhị phân sẽ trở thành đúng bốn ký tự đầu ra, vì bội chung nhỏ nhất của 6 bit (một ký tự Base64) và 8 bit (một byte) là 24. Tỉ lệ bốn-trên-ba đó cũng là lý do tại sao một file được mã hóa Base64 lớn hơn nhị phân gốc khoảng 33%.
Khi độ dài đầu vào không phải bội số của ba, Base64 đệm thêm = để đầu ra luôn là bội số của bốn ký tự: một byte đuôi tạo ra hai ký tự cộng ==; hai byte đuôi tạo ra ba ký tự cộng =. Một số bộ mã hóa bỏ phần đệm, vì vậy một bộ giải mã vững chắc cần đệm lại trước khi truyền chuỗi vào atob().
RFC 4648 cũng định nghĩa một biến thể an toàn với URL (đôi khi gọi là base64url) hoán đổi + thành - và / thành _. JWT dùng biến thể này. Bộ giải mã này chuẩn hóa cả hai bảng chữ cái nên bạn không cần nghĩ xem mình đang nhận cái nào.
Lược đồ data URI
RFC 2397 (tháng 8 năm 1998) định nghĩa lược đồ URL data:. Cú pháp đầy đủ là:
data:[<mediatype>][;base64],<data>Một PNG nội tuyến điển hình trông như data:image/png;base64,iVBORw0KGgo…. Token ;base64 là một dấu hiệu (lưu ý sự vắng mặt của dấu =) báo cho trình duyệt giải mã payload từ Base64 thay vì xử lý nó là văn bản mã hóa phần trăm. Nếu bạn bỏ ;base64, dữ liệu sẽ được hiểu là văn bản mã hóa URL. Nếu bạn bỏ hoàn toàn loại media, đặc tả mặc định là text/plain;charset=US-ASCII.
Bộ giải mã này chấp nhận cả hai dạng: dán data URI đầy đủ hoặc chỉ payload Base64. Khi chỉ cung cấp payload, định dạng được phát hiện từ các byte đầu tiên được giải mã, xem bên dưới.
Cách phát hiện định dạng
Nếu bạn dán một chuỗi Base64 thô không có tiền tố data:image/…, cách duy nhất để biết đó là loại ảnh gì là nhìn vào một vài byte đầu tiên được giải mã, mỗi định dạng ảnh phổ biến đều bắt đầu bằng một chữ ký nhận dạng được, chính thức gọi là «magic number». Các trình duyệt thực hiện đúng cách kiểm tra đó khi dò tìm MIME type (quy trình này có trong tiêu chuẩn WHATWG MIME Sniffing). Điểm tiện lợi là những chữ ký đó chuyển thành tiền tố Base64 có thể dự đoán được:
| Định dạng | Byte đầu (hex) | Tiền tố Base64 |
|---|---|---|
| PNG | 89 50 4E 47 0D 0A 1A 0A | iVBORw0KGgo |
| JPEG | FF D8 FF | /9j/ |
| GIF89a | 47 49 46 38 39 61 | R0lGODlh |
| WebP | 52 49 46 46 … 57 45 42 50 | UklGR |
| BMP | 42 4D ("BM") | Qk |
| SVG (văn bản XML) | bắt đầu bằng <?xml hoặc <svg | PD94bWwg hoặc PHN2Zw |
Chữ ký của PNG là một trong những chữ ký khéo léo nhất trong vườn thú định dạng. Byte 89 có bit cao được đặt để bộ chuyển tiếp thư chỉ 7-bit sẽ làm hỏng nó một cách rõ ràng. Ba byte tiếp theo ghép thành PNG trong ASCII để người dùng chạy head trên file có thể nhận ra. Tiếp theo là ký tự kết thúc dòng DOS (0D 0A), Ctrl-Z của MS-DOS dừng lệnh TYPE cũ không in tiếp, và ký tự xuống dòng Unix (0A), cùng nhau chúng phát hiện mọi phương tiện truyền tải phổ biến «hữu ích» ghi đè các ký tự xuống dòng.
Base64 image đến từ đâu
Hầu hết những người dùng công cụ như thế này đều đang gỡ lỗi thứ gì đó. Các tình huống phổ biến:
- Phản hồi từ JSON API. JSON không có kiểu nhị phân gốc, vì vậy các API gửi ảnh, PDF có chữ ký, ảnh hồ sơ và ảnh chụp màn hình đã tải lên dưới dạng chuỗi Base64 bên trong các trường JSON. Dán giá trị vào đây cho phép bạn thấy nó thực sự là gì.
- CSS và asset được đóng gói. Webpack và Vite có ngưỡng asset nhỏ (Vite mặc định là 4 KB) tự động nhúng ảnh nhỏ dưới dạng data URI vào CSS hoặc JS đã đóng gói. Khi gỡ lỗi «icon này đến từ đâu vậy?» thì data URI đó kết thúc ở đây.
- Chữ ký email HTML. Gmail, Outlook và Apple Mail nhúng ảnh chữ ký dưới dạng data URI để ảnh tồn tại qua quá trình chuyển tiếp. Các nhà thiết kế đôi khi cần lấy lại logo gốc.
- Xuất từ CMS và Notion. Xuất XML WordPress, xuất Notion và sao lưu Confluence nhúng hình thu nhỏ dưới dạng Base64 để giữ bản xuất tự đủ.
- Mã QR và bảng chữ ký. Các thư viện trình duyệt tạo mã QR (qrcode.js) hoặc ghi lại chữ ký tay (signature_pad) thường hiển thị đầu ra của chúng dưới dạng chuỗi
data:image/png;base64,…. - Tạo PDF phía máy chủ. Các công cụ như Puppeteer, openhtmltopdf và iText chấp nhận HTML có data URI nội tuyến. Khi logo «không hiển thị» trong PDF được kết xuất, giải mã URI là cách nhanh nhất để xem liệu các byte đó có phải là ảnh hay không.
Bạn có nên nhúng ảnh dưới dạng Base64 không?
Sự đánh đổi từng thú vị hơn. Dưới HTTP/1.1, mỗi ảnh là một yêu cầu chặn riêng biệt và nhúng một icon nhỏ có thể tiết kiệm được một lần round-trip thực sự. Dưới HTTP/2 và HTTP/3, tình huống này đã thu hẹp đáng kể. Tóm tắt thật thà:
Bạn được: không có yêu cầu HTTP thêm, phân phối nguyên tử, và các artifact tự đủ hoạt động không cần phụ thuộc bên ngoài (demo đơn file, email, PDF kết xuất phía máy chủ).
Bạn mất: trình duyệt không thể cache data URI nội tuyến riêng biệt, vì vậy cùng một ảnh trên mười trang được tải lại với mỗi phản hồi HTML. Asset được mã hóa lớn hơn khoảng 33% so với nhị phân tương đương. CDN không thể loại bỏ trùng lặp ảnh được nhúng trên các trang. Các pipeline tối ưu hóa ảnh (Cloudinary, Vercel, Next.js <Image>) không thể kiểm tra, nén, thay đổi kích thước hoặc phục vụ các định dạng hiện đại như AVIF hay WebP cho asset được nhúng. Trình duyệt cũng phải giải mã Base64 trước và ảnh sau, tốn thêm CPU cho mỗi lần kết xuất.
Quy tắc ngón tay cái hợp lý: nhúng ảnh nhỏ hơn khoảng 4 KB chỉ dùng ở một chỗ, placeholder một pixel, và ảnh cần di chuyển bên trong file tự đủ. Đừng nhúng bất cứ thứ gì dùng trên nhiều hơn một trang, bất cứ thứ gì lớn hơn khoảng 4 KB, bất cứ thứ gì nên được lazy-load, hay bất cứ thứ gì được hưởng lợi từ đàm phán định dạng.
Bảo mật: những gì Base64 không làm
Base64 là mã hóa, không phải mật mã. RFC 4648 §12 cảnh báo rõ ràng rằng nó «che giấu thị giác» dữ liệu nhưng không cung cấp «bảo mật tính toán», bất kỳ ai cũng có thể giải mã ngay lập tức. Đừng Base64-encode mật khẩu hay API key rồi nghĩ đó là biện pháp bảo mật.
Hai chi tiết bảo mật đáng biết:
- Điều hướng cấp cao nhất đến URL
data:bị chặn trong các trình duyệt hiện đại (mở một URL như vậy trong tab mới sẽ không hoạt động) để giảm thiểu các cuộc tấn công lừa đảo tạo trang đăng nhập giả từ data URI. Sử dụng làm subresource (<img src="data:…">, CSSurl(data:…)) vẫn được cho phép. - SVG là đặc biệt. SVG là XML và tài liệu SVG có thể chứa các phần tử
<script>và trình xử lý sự kiện. Tải SVG vào thẻ<img>là an toàn (trình duyệt chạy bộ kết xuất đã tắt script), nhưng tải cùng SVG đó vào<object>hoặc<iframe>có thể thực thi JavaScript tùy ý. Bộ giải mã này chỉ đặt<img src>, đó là con đường an toàn. Nếu bạn đã giải mã SVG từ nguồn không đáng tin, hãy xử lý file đó như bất kỳ tài liệu không đáng tin nào khác.
Câu hỏi thêm
Tại sao chuỗi Base64 của tôi thất bại với «InvalidCharacterError»?
Ba nguyên nhân thường gặp: khoảng trắng hoặc ký tự xuống dòng lạc từ copy-paste (chuẩn MIME Base64 cũ hơn ngắt dòng tại 76 ký tự, mà atob() của JavaScript từ chối); Base64 an toàn với URL dùng - và _ thay vì + và /; hoặc phần đệm = đuôi bị cắt khiến độ dài không phải bội số của bốn. Bộ giải mã này làm sạch khoảng trắng, chuẩn hóa bảng chữ cái và đệm lại trước khi giải mã, nhưng các chuỗi bị hỏng nặng vẫn thất bại.
Tôi có mất chất lượng khi giải mã không?
Không. Giải mã là nghịch đảo chính xác của mã hóa, bạn lấy lại ảnh gốc byte theo byte. File tải xuống ở bất kỳ định dạng nào trong Base64 (PNG, JPEG, WebP, GIF, BMP hoặc SVG), không có bước mã hóa lại.
Data URI lớn nhất mà trình duyệt chấp nhận là bao nhiêu?
Theo MDN, giới hạn hiện tại vào khoảng 512 MB cho Chromium và Firefox, và khoảng 2 GB cho Safari/WebKit. Trong thực tế, nút cổ chai là bộ nhớ và CPU chứ không phải đặc tả URL, các lần dán trên khoảng 10 MB bắt đầu cảm thấy chậm chạp trên máy tính xách tay thông thường.
Có dữ liệu nào được gửi lên máy chủ không?
Không. Giải mã xảy ra hoàn toàn trong trình duyệt của bạn thông qua hàm atob() gốc và Blob hoặc data URI được gán cho thẻ <img>. Không có gì được tải lên; trang hoạt động ngoại tuyến sau khi đã tải.
Tại sao Base64 của mọi JPEG đều bắt đầu bằng /9j/?
Hầu hết mọi file JPEG trong thực tế đều bắt đầu bằng các byte FF D8 FF (dấu Start-Of-Image theo sau là một byte dấu khác). Khi bạn mã hóa Base64 ba byte tất cả đều là FF với D8 ở giữa, mẫu bit 11111111 11011000 11111111 chia thành các nhóm 6-bit 111111 111101 100011 111111: vị trí bảng chữ cái Base64 63, 61, 35, 63, ghép thành /9j/. Ký tự thứ tư sau đó thay đổi tùy thuộc vào dấu theo sau (E0 cho JFIF, E1 cho Exif), nhưng ba ký tự đầu là bất biến.