Base64 Gambar Pengdekode
Tempel string Base64 untuk pratinjau dan unduh gambar.
Cara menggunakan
- Tempel string gambar yang dienkode Base64 ke dalam kotak input. Bisa menyertakan awalan
data:image/…atau hanya berisi data Base64 mentah. - Klik Dekode gambar untuk pratinjau.
- Klik Unduh gambar untuk menyimpannya sebagai file PNG.
Pertanyaan umum
Format Base64 apa saja yang didukung?
Anda dapat menempel string Base64 mentah (alat mendeteksi format secara otomatis) atau URI data lengkap seperti data:image/png;base64,iVBOR…. Jenis gambar yang didukung: PNG, JPEG, WebP, GIF, BMP, dan SVG.
Apakah ada batas ukuran?
Tidak ada batas tegas, tetapi string Base64 yang sangat besar (lebih dari 5–10 MB) mungkin perlu waktu untuk diproses tergantung perangkat Anda.
Bagaimana saya mengenkode gambar ke Base64?
Gunakan alat Gambar ke Base64 Konverter kami · cukup seret-jatuhkan gambar untuk mendapatkan string Base64-nya.
Apa sebenarnya Base64 itu
Base64 adalah skema enkoding biner-ke-teks yang didefinisikan dalam RFC 4648 (Oktober 2006). Ia menggunakan alfabet 64-karakter, A-Z, a-z, 0-9, ditambah + dan /: untuk merepresentasikan byte sembarang sebagai ASCII yang dapat dicetak. Setiap tiga byte input biner menjadi tepat empat karakter output, karena kelipatan persekutuan terkecil dari 6 bit (satu karakter Base64) dan 8 bit (satu byte) adalah 24. Rasio empat-ke-tiga itu juga mengapa file yang di-encode Base64 kira-kira 33% lebih besar dari biner aslinya.
Ketika panjang input bukan kelipatan tiga, Base64 melakukan padding dengan = sehingga keluaran selalu kelipatan empat karakter: satu byte trailing menghasilkan dua karakter ditambah ==; dua byte trailing menghasilkan tiga karakter ditambah =. Beberapa encoder membuang padding, sehingga decoder yang robust perlu re-pad sebelum meneruskan string ke atob().
RFC 4648 juga mendefinisikan varian aman-URL (kadang disebut base64url) yang mengganti + dengan - dan / dengan _. JWT menggunakannya. Decoder ini menormalkan kedua alfabet sehingga Anda tidak perlu memikirkan mana yang Anda terima.
Skema URI data
RFC 2397 (Agustus 1998) mendefinisikan skema URL data:. Tata bahasa lengkapnya adalah:
data:[<mediatype>][;base64],<data>PNG inline tipikal terlihat seperti data:image/png;base64,iVBORw0KGgo…. Token ;base64 adalah penanda (perhatikan tidak adanya tanda =) yang memberi tahu browser untuk mendekode payload dari Base64 alih-alih memperlakukannya sebagai teks yang di-persen-enkode. Jika Anda menghilangkan ;base64, data diinterpretasikan sebagai teks yang di-URL-enkode. Jika Anda menghilangkan tipe media sepenuhnya, spec default ke text/plain;charset=US-ASCII.
Decoder ini menerima kedua bentuk: tempel URI data lengkap atau hanya payload Base64. Ketika hanya payload yang diberikan, format dideteksi dari byte pertama yang didekode, lihat di bawah.
Cara format dideteksi
Jika Anda menempelkan string Base64 mentah tanpa prefiks data:image/…, satu-satunya cara untuk mengetahui jenis gambarnya adalah dengan melihat beberapa byte pertama yang didekode, setiap format gambar umum dimulai dengan tanda tangan yang dapat dikenali, secara formal disebut «magic number». Browser melakukan pemeriksaan yang sama persis saat mengendus tipe MIME (prosedurnya ada dalam standar MIME Sniffing WHATWG). Pintasannya adalah bahwa tanda tangan tersebut diterjemahkan menjadi prefiks Base64 yang dapat diprediksi:
| Format | Byte pertama (hex) | Prefiks 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 (teks XML) | dimulai dengan <?xml atau <svg | PD94bWwg atau PHN2Zw |
Tanda tangan PNG adalah salah satu yang paling cerdas dalam kebun binatang format. Byte 89 memiliki bit tinggi yang disetel sehingga relay email hanya-7-bit merusaknya secara terlihat. Tiga byte berikutnya mengeja PNG dalam ASCII sehingga manusia yang menjalankan head pada file dapat mengenalinya. Kemudian muncul akhir baris DOS (0D 0A), MS-DOS Ctrl-Z yang menghentikan perintah TYPE lama agar tidak mencetak lebih jauh, dan line feed Unix (0A), antara keduanya mereka mendeteksi setiap transport umum yang «dengan membantu» menulis ulang akhir baris.
Dari mana gambar Base64 berasal
Kebanyakan orang yang mendarat di alat seperti ini sedang men-debug sesuatu. Situasi umum:
- Respons API JSON. JSON tidak memiliki tipe biner native, sehingga API mengirimkan gambar, PDF yang ditandatangani, foto profil, dan screenshot yang diunggah sebagai string Base64 di dalam field JSON. Menempelkan nilainya di sini memungkinkan Anda melihat apa sebenarnya itu.
- CSS dan aset yang di-bundle. Webpack dan Vite memiliki ambang aset-kecil (Vite default ke 4 KB) yang secara otomatis menyisipkan gambar kecil sebagai data URI dalam CSS atau JS yang di-bundle. Saat men-debug «dari mana ikon ini berasal?» URI data berakhir di sini.
- Tanda tangan email HTML. Gmail, Outlook, dan Apple Mail menyisipkan gambar tanda tangan secara inline sebagai data URI sehingga gambar dapat bertahan dari penerusan. Desainer kadang-kadang membutuhkan logo asli kembali.
- Ekspor CMS dan Notion. Ekspor XML WordPress, ekspor Notion, dan backup Confluence menyematkan thumbnail secara inline sebagai Base64 agar ekspor berdiri sendiri.
- Kode QR dan pad tanda tangan. Library browser yang menghasilkan kode QR (qrcode.js) atau menangkap tanda tangan tulisan tangan (signature_pad) biasanya mengekspos keluarannya sebagai string
data:image/png;base64,…. - Pembuatan PDF sisi server. Alat seperti Puppeteer, openhtmltopdf, dan iText menerima HTML dengan data URI inline. Ketika logo «tidak muncul» dalam PDF yang dirender, mendekode URI adalah cara tercepat untuk melihat apakah byte tersebut bahkan berupa gambar.
Haruskah Anda menyisipkan gambar sebagai Base64?
Trade-off ini dulu lebih menarik. Di bawah HTTP/1.1 setiap gambar adalah permintaan pemblokiran terpisah dan menyisipkan ikon kecil bisa menghemat round-trip nyata. Di bawah HTTP/2 dan HTTP/3 kasusnya menyempit tajam. Ringkasan jujur:
Anda mendapat: nol permintaan HTTP tambahan, pengiriman atomik, dan artefak yang berdiri sendiri yang berfungsi tanpa dependensi eksternal (demo file tunggal, email, PDF yang dirender server).
Anda kehilangan: browser tidak dapat menyimpan data URI yang disisipkan secara terpisah, sehingga gambar yang sama di sepuluh halaman diunduh ulang dengan setiap respons HTML. Aset yang di-encode kira-kira 33% lebih besar dari padanan binernya. CDN tidak dapat mendeduplikasi gambar yang disematkan di berbagai halaman. Pipeline optimisasi gambar (Cloudinary, Vercel, <Image> Next.js) tidak dapat memeriksa, mengompresi, mengubah ukuran, atau melayani format modern seperti AVIF atau WebP untuk aset yang disisipkan. Browser juga harus mendekode Base64 terlebih dahulu dan gambar kedua, yang merupakan CPU ekstra pada setiap render.
Aturan praktis yang masuk akal: sisipkan gambar yang lebih kecil dari sekitar 4 KB yang hanya digunakan di satu tempat, placeholder satu piksel, dan gambar yang perlu dibawa di dalam file yang berdiri sendiri. Jangan sisipkan apa pun yang digunakan di lebih dari satu halaman, apa pun yang lebih besar dari sekitar 4 KB, apa pun yang harus di-lazy-load, atau apa pun yang mendapat manfaat dari negosiasi format.
Keamanan: apa yang tidak dilakukan Base64
Base64 adalah enkoding, bukan enkripsi. RFC 4648 §12 secara eksplisit memperingatkan bahwa ia «secara visual menyembunyikan» data tetapi tidak memberikan «kerahasiaan komputasional», siapa pun dapat mendekodenya secara instan. Jangan meng-encode password atau kunci API dengan Base64 dengan mengira itu adalah tindakan keamanan.
Dua detail keamanan yang perlu diketahui:
- Navigasi tingkat atas ke URL
data:diblokir di browser modern (membukanya di tab baru tidak akan berhasil) untuk mengurangi serangan phishing yang merender halaman login palsu dari data URI. Penggunaan subresource (<img src="data:…">, CSSurl(data:…)) masih diizinkan. - SVG bersifat khusus. SVG adalah XML dan dokumen SVG dapat mengandung elemen
<script>dan event handler. Memuat SVG ke dalam tag<img>aman (browser menjalankan renderer yang menonaktifkan skrip), tetapi memuat SVG yang sama ke dalam<object>atau<iframe>dapat mengeksekusi JavaScript sembarang. Decoder ini hanya pernah menyetel<img src>, yang merupakan jalur aman. Jika Anda mendekode SVG dari sumber yang tidak tepercaya, perlakukan file tersebut seperti dokumen yang tidak tepercaya lainnya.
Pertanyaan lainnya
Mengapa string Base64 saya gagal dengan «InvalidCharacterError»?
Tiga penyebab biasa: spasi atau baris baru yang tersesat dari copy-paste (profil MIME Base64 yang lebih lama membungkus baris pada 76 karakter, yang ditolak oleh atob() JavaScript); Base64 aman-URL dengan - dan _ alih-alih + dan /; atau padding = trailing yang dihapus sehingga panjangnya bukan kelipatan empat. Decoder ini membersihkan spasi, menormalkan alfabet, dan re-pad sebelum mendekode, tetapi string yang sangat rusak tetap gagal.
Apakah saya kehilangan kualitas saat mendekode?
Tidak. Dekoding adalah kebalikan tepat dari enkoding, Anda mendapatkan kembali gambar asli byte-per-byte. Unduhan dalam format apa pun yang ada di Base64 (PNG, JPEG, WebP, GIF, BMP, atau SVG), tanpa langkah re-enkoding.
Apa data URI terbesar yang dapat diterima browser?
Menurut MDN, batas saat ini adalah sekitar 512 MB untuk Chromium dan Firefox, dan sekitar 2 GB untuk Safari/WebKit. Dalam praktiknya bottleneck adalah memori dan CPU daripada spec URL, pasta di atas sekitar 10 MB mulai terasa lambat di laptop biasa.
Apakah ada yang dikirim ke server?
Tidak. Dekoding terjadi sepenuhnya di browser Anda melalui fungsi atob() native dan Blob atau data URI yang ditetapkan ke tag <img>. Tidak ada yang diunggah; halaman berfungsi secara offline setelah dimuat.
Mengapa Base64 setiap JPEG selalu dimulai dengan /9j/?
Hampir setiap file JPEG di alam liar dimulai dengan byte FF D8 FF (penanda Start-Of-Image diikuti byte penanda lainnya). Ketika Anda meng-encode Base64 tiga byte yang semuanya FF dengan D8 di tengah, pola bit 11111111 11011000 11111111 terbagi menjadi grup 6-bit 111111 111101 100011 111111: posisi alfabet Base64 63, 61, 35, 63, yang mengeja /9j/. Karakter keempat kemudian bervariasi tergantung penanda apa yang mengikuti (E0 untuk JFIF, E1 untuk Exif), tetapi tiga yang pertama bersifat universal.