Gambar ke Base64

Apa itu gambar Base64 (data URI)?

Sebuah data URI menyematkan gambar langsung di dalam teks alih-alih menunjuk ke berkas terpisah. Bentuknya adalah data:<mime>;base64,<encoded-bytes> — misalnya data:image/png;base64,iVBORw0KGgo…. Karena ini teks biasa, Anda bisa memasukkannya langsung ke HTML, CSS, JSON, SVG, atau Markdown, dan browser merender gambar tanpa permintaan jaringan kedua. Meng-encode tidak pernah mengubah gambarnya — ia adalah representasi teks byte-per-byte dari berkas persis yang Anda berikan.

Ukuran & caching — imbalannya

Base64 mengubah setiap 3 byte menjadi 4 karakter ASCII, jadi teks hasil encode selalu sekitar 33% lebih besar daripada berkas binernya, ditambah header pendek. Ini wajar untuk beberapa aset yang sangat kecil tetapi boros untuk yang besar. Jebakan yang lebih besar adalah caching: berkas gambar yang ditautkan diunduh dan di-cache sekali, lalu dipakai ulang di mana pun, sedangkan data URI inline diunduh ulang sebagai bagian dari setiap halaman atau stylesheet yang memuatnya, dan tidak bisa di-cache sendiri. Sisipkan yang kecil, tautkan yang besar.

Kapan inline versus kapan menautkan

Tips

• Kompres atau ubah ukurannya dulu. Base64 dari gambar yang lebih kecil menghasilkan string yang lebih pendek — jalankan foto melalui Kompresor Gambar atau Pengubah Ukuran Gambar sebelum meng-encode.
• SVG sangat cocok disisipkan inline — ikon vektor tetap tajam dan terkompresi lebih baik daripada raster sebagai Base64; bagus untuk background CSS dan pustaka komponen.
• Perhatikan ukuran HTML/CSS. Beberapa ikon inline tidak masalah; puluhan data URI besar membuat markup Anda berat dan lambat diurai.
• Butuh teks, bukan gambar? Gunakan Base64 Encoder / Decoder untuk teks biasa dan string.

Bagaimana Base64 sebenarnya bekerja

Base64 adalah cara menuliskan data biner hanya dengan sekumpulan kecil karakter teks yang aman. Alfabetnya tepat 64 simbol — huruf kapital A–Z, huruf kecil a–z, angka 0–9, ditambah + dan / — dan standarnya didefinisikan dalam RFC 4648. Encoding bekerja dalam irama tetap: ia mengambil data tiga byte (24 bit) sekaligus dan menuliskannya ulang sebagai empat karakter berukuran 6 bit (karena 2⁶ = 64, setiap karakter terpetakan rapi ke satu simbol alfabet). Ketika data tidak habis dibagi tiga, satu atau dua karakter = mengisi bagian akhir sebagai padding.

Rasio 3-byte-menjadi-4-karakter itulah tepatnya asal kenaikan ukuran ~33%: empat karakter keluaran untuk setiap tiga byte masukan berarti pemekaran 4/3. Ada pula sepupu yang umum, base64url, yang menukar + dan / dengan - dan _ sehingga hasilnya aman dimasukkan ke URL atau nama berkas tanpa escaping tambahan — varian inilah yang dipakai di dalam JSON Web Tokens (JWTs).

Skema data URI

Membungkus Base64 itu menjadi alamat yang bisa dipakai adalah tugas skema data URI, yang didefinisikan dalam RFC 2397 pada 1998 oleh Larry Masinter. Tata bahasanya adalah data:[<mediatype>][;base64],<data>. Beberapa detail patut diketahui: koma selalu wajib, bahkan untuk data kosong; token ;base64 itulah yang menandakan bahwa payload berupa Base64, bukan teks percent-encoded; dan jika Anda menghilangkan tipe media sepenuhnya, defaultnya adalah text/plain;charset=US-ASCII. Untuk sebuah gambar, Anda akan selalu melihat tipe eksplisit seperti data:image/png;base64,… agar browser tahu cara men-decode-nya. Ini juga sebabnya alat ini melaporkan tipe MIME — tipe itu dibaca langsung dari berkas Anda, sehingga URI-nya tepat untuk format tersebut.

Mengapa Base64 ada sama sekali

Base64 tidak diciptakan untuk web — ia berasal dari email. Protokol surat yang asli dirancang hanya untuk membawa teks ASCII 7-bit, tanpa cara aman untuk mengirim byte sembarang dari sebuah gambar atau lampiran. Standar MIME menyelesaikannya dengan meng-encode ulang data biner ke dalam alfabet teks yang selamat melewati kanal teks apa pun, dan Base64 menjadi encoding tersebut. Sebuah data URI adalah gagasan yang sama yang diterapkan pada halaman web: ubah gambar menjadi teks agar ia bisa berada di dalam HTML atau CSS alih-alih menjadi berkas terpisah.

Sejarah ini menunjuk pada hal terpenting yang perlu dipahami tentang Base64: ia adalah encoding, bukan kompresi dan bukan enkripsi. Ia tidak membuat data lebih kecil — ia membuatnya sekitar sepertiga lebih besar — dan ia tidak mengamankan apa pun, karena siapa saja bisa men-decode-nya seketika (alat ini pun bisa). Jika Anda melihat Base64 lalu menganggapnya "terenkripsi", Anda keliru; ia hanyalah data biner yang berbusana teks terbaca.

Apakah inline masih membantu performa?

Argumen klasik untuk data URI adalah menghilangkan permintaan HTTP, dan di bawah HTTP/1.1 — ketika browser hanya bisa membuka beberapa koneksi per host — menghemat satu perjalanan bolak-balik adalah kemenangan nyata. HTTP/2 mengubah hitungannya: ia memultipleks banyak berkas melalui satu koneksi, sehingga biaya permintaan tambahan turun tajam dan alasan untuk inline melemah. Ada pula pajak yang lebih halus: teks Base64 terkompresi kurang efisien dengan gzip atau Brotli dibandingkan data biner mentah yang setara, jadi sebagian byte yang Anda "hemat" pada permintaan kembali lagi di jalur transmisi. Patokan yang tahan lama sederhana saja — sisipkan yang kecil, tautkan yang besar — satu ikon kritis yang mungil masih layak disisipkan inline untuk menghindari permintaan yang render-blocking, tetapi apa pun yang berukuran berarti sebaiknya tetap menjadi berkas biasa yang bisa di-cache terpisah. (Satu pengecualian menarik: untuk sebuah SVG, meng-URL-encode markup-nya biasanya lebih kecil daripada meng-encode-nya dengan Base64, karena SVG sudah berupa teks dan tidak diuntungkan oleh pembungkus Base64.)

Catatan tentang keamanan dan Content Security Policy

Karena sebuah data URI bisa membawa konten apa pun, implikasi keamanannya patut disorot. Di bawah Content Security Policy, mengizinkan data: pada img-src adalah hal umum dan cukup rendah risiko (begitulah cara ikon inline bekerja), tetapi mengizinkan data: pada script-src berbahaya — penyerang bisa menyelundupkan dan menjalankan kode lewat URL skrip data:, sehingga panduan keamanan menyarankan untuk tidak pernah mengizinkannya di sana. Data URI juga pernah disalahgunakan untuk membangun halaman phishing, itulah sebabnya browser modern kini memblokir navigasi tingkat atas langsung ke URL data:. Tidak satu pun dari ini memengaruhi proses meng-encode gambar untuk halaman Anda sendiri; ini hanya berarti Anda sebaiknya memperlakukan data URI sebagai konten aktif sebagaimana adanya, bukan sebagai teks pasif.

API browser di baliknya

Konverter ini dibangun di atas FileReader.readAsDataURL() milik browser sendiri, yang membaca berkas Anda secara lokal dan mengembalikan string data:<mime>;base64,… yang lengkap — keluaran "Base64 mentah" hanyalah string tersebut dengan prefiksnya dilepas. Anda mungkin juga pernah menemui btoa() dan atob(), fungsi encode dan decode tingkat rendah itu. Keduanya menyimpan jebakan terkenal: btoa() memperlakukan setiap karakter sebagai satu byte, sehingga ia melempar galat pada karakter apa pun di atas U+00FF — beri ia emoji atau karakter non-Latin dan ia gagal. Solusi modernnya adalah mengubah teks menjadi byte dengan TextEncoder lebih dulu (atau memakai helper Base64 Uint8Array yang lebih baru). Untuk gambar hal ini tidak pernah muncul, karena readAsDataURL bekerja pada byte mentah — dan justru itulah sebabnya ia adalah alat yang tepat di sini.

Ke mana sebenarnya data URI dipakai

Setelah Anda punya string hasil encode, pertanyaannya adalah ke mana menempelkannya. Data URI yang sama bekerja di beberapa konteks, itulah sebabnya alat ini membuatkan snippet siap pakai untuk konteks yang umum:

Masing-masing menyematkan gambar langsung ke dalam dokumen, sehingga tidak ada permintaan kedua untuk berkas gambar terpisah. Itulah seluruh daya tariknya — dan, seperti dibahas di atas, seluruh imbalannya juga, karena byte-nya ikut terbawa di dalam berkas induk setiap kali dimuat.

Mengapa data URI andal di email

Satu konteks layak disebut khusus: email. Banyak klien email memblokir gambar jarak jauh secara default — mereka tidak memuat gambar yang dihosting di server eksternal sampai pembaca mengklik "tampilkan gambar", sebagian sebagai langkah privasi terhadap piksel pelacak. Gambar yang disematkan sebagai data URI sepenuhnya melewati hal itu, karena tidak ada yang perlu diambil dari mana pun; gambarnya sudah berada di dalam pesan. Itu menjadikan data URI cara yang dapat diandalkan untuk memasang logo kecil di tanda tangan email HTML, di mana Anda ingin ia tampil setiap kali, di setiap klien, tanpa placeholder gambar rusak. Kehati-hatian yang sama tetap berlaku — jaga tetap kecil, karena byte hasil encode ikut bepergian di dalam setiap salinan email.

Biaya caching, dijelaskan gamblang

Perlu bersikap konkret tentang kelemahan terbesarnya, karena inilah yang sering diabaikan orang. Gambar biasa yang ditautkan diunduh sekali lalu disajikan dari cache browser pada setiap halaman berikutnya — cepat, dan bebas byte tambahan. Data URI inline tidak bisa di-cache sendiri; ia berada di dalam berkas HTML atau CSS, sehingga ia diunduh ulang sebagai bagian dari berkas itu setiap kali berkasnya berubah, dan tidak bisa dibagi antar halaman. Sisipkan ikon yang sama di dua puluh halaman dan browser secara efektif mengunduhnya dua puluh kali alih-alih menyimpan satu salinan di cache. Inilah faktor penentu di balik aturan "sisipkan yang kecil, tautkan yang besar": satu aset mungil sekali pakai boleh saja disematkan, tetapi apa pun yang dipakai ulang lintas halaman hampir selalu layak berada di berkas terpisah yang bisa di-cache.

Anatomi sebuah data URI, field demi field

Sebuah data URI tampak seperti dinding karakter acak, padahal ia punya struktur yang jelas dan bisa dibaca. Ambil data:image/png;base64,iVBORw0KGgo… lalu pecah menjadi bagian-bagiannya:

Bahkan ada petunjuk menarik yang tersembunyi di payload: string Base64 yang diawali iVBORw0KGgo hampir selalu berupa PNG (karakter-karakter itu meng-encode tanda tangan berkas PNG), sedangkan yang diawali /9j/ adalah JPEG. Begitu Anda bisa membaca bagian-bagiannya, data URI berhenti menjadi misteri — ia hanyalah tipe media, kata base64, dan berkas hasil encode, yang disambung dengan sebuah koma. Itulah persis string yang diberikan kotak "Data URI" alat ini, dan kotak "Base64 mentah" adalah hal yang sama dengan segala sesuatu sampai dengan koma itu dihapus.

Mengubah data URI kembali menjadi berkas

Karena Base64 adalah encoding yang dapat dibalik, prosesnya berjalan dua arah — dan itulah yang dilakukan tab "Base64 → Gambar" di atas. Tempelkan data URI data: yang lengkap, atau cukup Base64 mentah dengan formatnya dipilih, dan alat ini men-decode teks kembali ke byte aslinya, menampilkan pratinjau gambarnya, serta memungkinkan Anda mengunduhnya sebagai berkas sungguhan. Proses decode hanya membalik setiap langkah: ia membaca tipe media untuk mengetahui format berkas, melepas prefiks data:…;base64,, dan mengubah setiap empat karakter Base64 kembali menjadi tiga byte. Jika string-nya bukan data gambar yang valid — biang keladi yang biasa adalah copy-paste yang terpotong — Anda akan mendapat galat yang jelas alih-alih gambar rusak, karena byte-nya tidak akan ter-decode menjadi gambar yang bisa dirender browser. Ini kebalikan persis dari encoding, dan cara praktis untuk memulihkan gambar yang disematkan seseorang sebagai data URI di sebuah stylesheet atau berkas HTML.

Pertanyaan yang sering diajukan

Apakah gambar saya diunggah ke server?

Tidak. Gambar dibaca sepenuhnya di browser Anda dengan FileReader API bawaan dan diubah menjadi Base64 secara lokal — gambar tidak pernah meninggalkan perangkat Anda dan tidak pernah dicatat atau dikirim. Alat ini bahkan bekerja offline setelah halaman dimuat, itulah sebabnya aman untuk tangkapan layar pribadi, foto identitas, atau aset internal.

Apa itu data URI dan di mana saya menempelkan hasilnya?

Sebuah data URI terlihat seperti data:image/png;base64,iVBORw0KGgo… — tipe MIME, kata base64, lalu byte yang di-encode. Anda bisa memasukkan seluruh string itu langsung ke HTML <img src="…">, ke CSS background-image: url("…"), atau ke gambar Markdown. Alat ini membuatkan ketiga snippet tersebut untuk Anda sehingga Anda tinggal menyalin yang persis dibutuhkan.

Mengapa Base64 lebih besar daripada file aslinya?

Base64 meng-encode setiap 3 byte menjadi 4 karakter ASCII, jadi teksnya selalu sekitar 33% lebih besar daripada gambar binernya — ditambah header pendek data:…;base64,. Itulah imbalan dari menyematkan gambar langsung di dalam teks. Ini wajar untuk aset kecil tetapi boros untuk foto besar, yang lebih baik ditautkan sebagai file biasa.

Format gambar apa saja yang bisa saya encode?

Format apa pun yang bisa dibaca browser Anda sebagai berkas — PNG, JPEG, GIF, WebP, SVG, BMP, dan ICO semuanya berfungsi. Tipe MIME diambil dari berkas itu sendiri, sehingga data URI yang dihasilkan sudah tepat untuk format tersebut. Meng-encode tidak mengubah atau mengompresi ulang gambar; ia adalah representasi teks byte-per-byte dari berkas asli.

Bisakah saya men-decode string Base64 kembali menjadi gambar?

Bisa — beralihlah ke tab “Base64 → Gambar” lalu tempelkan data URI lengkap atau hanya Base64 mentahnya (lalu pilih formatnya). Alat ini menampilkan pratinjau gambar dan memungkinkan Anda mengunduhnya sebagai berkas sungguhan. Jika string tersebut bukan data gambar yang valid, Anda akan mendapat pesan galat yang jelas, bukan gambar rusak.

Apakah menyisipkan gambar sebagai Base64 membantu kecepatan halaman?

Untuk beberapa aset yang sangat kecil, ya — cara ini menghilangkan permintaan HTTP tambahan. Namun gambar inline tidak bisa di-cache terpisah dan membengkakkan HTML/CSS, jadi untuk apa pun di luar ikon kecil biasanya justru merugikan. Patokan yang baik: sisipkan inline aset di bawah beberapa kilobyte dan tautkan semua yang lebih besar.

Alat terkait

• Base64 Encoder / Decoder (teks)
• Kompresor Gambar
• Pengubah Ukuran Gambar
• Gambar ke PDF

Lihat semua alat browser →