Gambar ke Base64 Konverter

Cara Kerjanya

1. Seret atau pilih gambar. Browser membaca file secara lokal dengan API FileReader. Tidak ada yang diunggah ke mana pun.
2. Encoder mengonversi byte-byte menggunakan alfabet Base64 standar, setiap 3 byte input menjadi 4 karakter ASCII yang diambil dari A-Z a-z 0-9 + /, dengan hingga dua karakter padding = di bagian akhir ketika panjang input bukan kelipatan 3.
3. Salin apa yang Anda butuhkan. «Copy Base64» memberikan hanya string yang dikodekan (berguna untuk payload JSON atau pemrosesan backend). «Copy Data URI» memberikan Anda form lengkap data:image/png;base64,… yang siap ditempel ke atribut <img src> atau CSS background-image: url(…).
4. Tempelkan di tempat yang sesuai. Output berupa teks biasa, berfungsi di HTML, CSS, JSON, JavaScript, Markdown, atau di mana pun sebuah string bisa berada.

Apa yang Sebenarnya Dilakukan Base64

Base64 didefinisikan dalam RFC 4648 (Oktober 2006). Pengkodean mengambil 24 bit input sekaligus (tiga byte) dan menulis ulangnya sebagai empat indeks 6-bit ke dalam alfabet 64 karakter. Matematikanya tepat: 3 byte (24 bit) → 4 karakter (masing-masing membawa 6 bit). Ketika panjang input bukan kelipatan 3, encoder menambahkan karakter padding = untuk membuat panjang output menjadi kelipatan 4.

Dua konsekuensi praktis:

• Output selalu ~33% lebih besar dari input. Rasio 4/3 adalah fundamental dari algoritma. Gambar 100 KB menjadi ~133 KB Base64. Dengan jeda baris bergaya MIME 76 karakter, overhead mendekati 37%.
• Output aman untuk teks di mana saja. Alfabet 64 karakter adalah irisan dari setiap saluran teks ASCII yang umum, HTML, JSON, XML, email, URL (dengan varian URL-safe), kode sumber. Itulah satu-satunya alasan Base64 ada: untuk memindahkan data biner melalui sistem yang dirancang untuk teks.

RFC 4648 §12 menegaskan satu fitur penting yang tidak dimiliki: «Base64 encoding visually hides otherwise easily recognized information, such as passwords, but does not provide any computational confidentiality.» Siapa pun dapat mendekode string Base64 dalam dua baris kode dalam bahasa apa pun. Ini adalah pengkodean, bukan enkripsi.

URI Data: Form Gambar Inline

«Data URI» adalah format pembungkus yang memungkinkan string Base64 menggantikan URL gambar. RFC 2397 (1998) mendefinisikan sintaksnya:

data:[<mediatype>][;base64],<data>

Untuk gambar, itu berarti data:image/png;base64,iVBORw0KGgo… dalam atribut <img src> atau background-image: url("data:image/svg+xml;utf8,<svg…>") dalam CSS. Token ;base64 memberi tahu browser bahwa bagian data dikodekan; tanpanya, data diperlakukan sebagai teks yang di-percent-encode. RFC 2397 sendiri mencatat bahwa URI data «hanya berguna untuk nilai pendek», sebuah petunjuk yang kini telah menjadi aturan kinerja yang ketat.

Kapan Anda Harus Meng-inline Gambar sebagai Base64

• Artefak satu file. Tanda tangan email dengan logo tertanam yang perlu bertahan saat diteruskan. Demo HTML mandiri untuk CodePen, JSFiddle, atau repro laporan bug. PDF yang dihasilkan di mana gambar harus disematkan agar file berfungsi secara offline.
• Ikon jalur-kritis yang sangat kecil. Chevron 200 byte atau spinner pemuatan yang di-inline ke dalam CSS kritis mungkin lebih cepat dimuat daripada memicu permintaan HTTP terpisah, terutama pada koneksi lambat.
• Respons JSON / API inline. Unggahan avatar, tanda tangan, sampel OCR, kode QR yang dihasilkan, apa pun di mana konsumen API mengharapkan byte secara inline daripada URL terpisah untuk diambil.
• Iframe yang di-sandbox atau konteks lain yang melarang pemuatan sumber daya eksternal.
• File konfigurasi di mana Anda tidak ingin file gambar saudara di samping JSON / TOML / YAML.

Kapan Anda Tidak Harus Meng-inline Gambar sebagai Base64

Untuk sebagian besar website produksi, gambar Base64 yang di-inline lebih lambat dari referensi <img> biasa. Lima alasan yang saling memperkuat:

1. Overhead ukuran 33%, selalu. Setiap byte menghabiskan 4/3 byte setelah dikodekan. Setelah gzip diterapkan, overhead yang tampak menyusut (karena Base64 bersifat repetitif), tetapi byte yang diurai browser masih 33% lebih besar dari aslinya.
2. Gambar tidak dapat di-cache secara terpisah. File image.png eksternal diambil sekali dan digunakan ulang di setiap halaman yang menautkannya. Gambar Base64 berada di dalam HTML atau CSS dan diunduh ulang dengan setiap perubahan pada file tersebut.
3. Memperlambat penguraian HTML dan CSS. String inline yang panjang di dalam CSS render-blocking mendorong jalur kritis lebih jauh. Harry Roberts (CSS Wizardry) mengukur stylesheet klien nyata sebesar 925 KB dengan gambar Base64 vs 708 KB tanpa, dan 232 KB setelah gzip vs 68 KB. Menghapus Base64 memangkas CSS yang di-gzip sebesar 70,68%.
4. Tidak dapat di-lazy-load. Atribut loading="lazy" menunda pengambilan gambar hingga pengguna menggulir mendekatinya. Gambar Base64 sudah ada di dalam dokumen, tidak ada yang perlu ditunda.
5. HTTP/2 dan HTTP/3 sudah memecahkan masalah «terlalu banyak permintaan». Multiplexing memungkinkan satu koneksi mengantarkan ratusan file secara paralel, sehingga pembenaran asli untuk inline sebagian besar sudah tidak berlaku.

Aturan praktis dari Google PageSpeed dan sebagian besar penulis kinerja: inline hanya jika gambar di bawah ~1-2 KB setelah dikodekan, dan hanya jika muncul di atas fold dalam CSS kritis. Apa pun yang lebih besar hampir pasti berkinerja lebih baik sebagai file terpisah.

SVG: Gunakan Pengkodean UTF-8, Bukan Base64

SVG sudah berupa teks, sehingga mengkodekannya sebagai Base64 membuang ~33% byte tanpa manfaat. Bentuk yang lebih kecil adalah UTF-8 yang di-URL-encode:

/* Base64 SVG (longer) */
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…");

/* URL-encoded SVG (shorter, also human-readable) */
background-image: url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' …>");

Sebagian besar build tool modern (PostCSS' postcss-inline-svg, Webpack's svg-url-loader) mengeluarkan form yang di-URL-encode secara default. Untuk SVG inline, pilih form tersebut daripada Base64 kecuali konsumen tertentu membutuhkan ;base64.

Tipe MIME yang Dikenali Alat Ini

Awalan jenis media URI data adalah yang memberi tahu konsumen cara menginterpretasikan byte. Browser mendeteksinya dari file yang Anda pilih:

Catatan Privasi dan Keamanan

Sebagian besar situs online «image to Base64» mengunggah file Anda ke server mereka, mengkode di sana, dan menyajikan hasilnya kembali. Itu berarti tangkapan layar UI pra-rilis, desain ber-NDA, foto anak-anak, pemindaian medis, atau tanda tangan pada kontrak melewati infrastruktur pihak ketiga. Alat ini mengkode secara lokal, FileReader browser membaca file ke dalam memori, encoder berjalan dalam JavaScript di perangkat Anda, dan satu-satunya yang meninggalkan halaman adalah string yang dikodekan ketika Anda menyalinnya.

Dua catatan Content Security Policy yang patut diketahui jika Anda mengirimkan gambar Base64 dalam produksi:

• Gambar Base64 inline melewati aturan img-src kecuali Anda secara eksplisit mengizinkannya. CSP yang ketat seperti img-src 'self' memblokir URI data:. Untuk mengizinkannya, tulis img-src 'self' data:.
• Hal yang sama berlaku untuk background image yang di-inline di CSS. Jika CSP memblokir background inline Anda, periksa direktif img-src terlebih dahulu.

Kesalahan Umum

1. Memperlakukan Base64 sebagai obfuskasi. Bukan begitu. Siapa pun bisa mendekodenya dalam dua baris bahasa apa pun. Jangan taruh kredensial, kunci API, atau data sensitif di dalam string Base64 «untuk menyembunyikannya.»
2. Meng-inline gambar hero 200 KB. Gambar menjadi 266 KB setelah dikodekan, terjebak di dalam HTML, tidak dapat di-cache secara terpisah, tidak dapat di-lazy-load, dan first paint halaman menjadi terlihat lebih lambat. Sajikan sebagai file biasa.
3. Menyalin Base64 mentah padahal Anda membutuhkan data URI. String Base64 telanjang dalam atribut <img src> dirender sebagai gambar rusak, Anda membutuhkan awalan data:image/png;base64,. Gunakan tombol «Copy Data URI».
4. Mengkode Base64 SVG. SVG sudah berupa teks. URL-encode saja dan hemat overhead 33%.
5. Melupakan CSP. img-src 'self' yang ketat memblokir URI data. Tambahkan data: ke direktif jika Anda mengirimkan gambar Base64.
6. Mencoba mendekode string Base64 dengan awalan data: terdepan. Bagian data:image/...;base64, adalah metadata; hapus sebelum meneruskan string ke dekoder Base64.
7. Menempelkan gambar rahasia ke encoder sisi server. Jika URL bertuliskan «encode» tetapi tab jaringan menunjukkan POST, gambar Anda baru saja meninggalkan perangkat Anda.

Pertanyaan yang Sering Diajukan

Apa perbedaan antara «Base64» dan «Data URI»?

Base64 adalah pengkodean (string seperti iVBORw0KGgo…. Data URI adalah pembungkus yang mengubah string Base64 menjadi sesuatu yang dapat menggantikan URL gambar) data:image/png;base64,iVBORw0KGgo…. Pembungkus tersebut memberi tahu browser tentang jenis media dan pengkodean sehingga tahu cara menginterpretasikan byte-nya. Dua tombol dalam alat ini memberikan masing-masing bentuk secara terpisah.

Apakah Base64 aman?

Tidak, dan bukan untuk itulah Base64 ada. Base64 adalah pengkodean, bukan enkripsi. RFC 4648 §12 menegaskannya secara langsung: Base64 «does not provide any computational confidentiality.» Siapa pun dapat mendekode string Base64 seketika. Jika Anda membutuhkan privasi, enkripsi data terlebih dahulu (dengan AES, dll.) lalu Base64-kan ciphertext untuk pengiriman.

Seberapa besar gambar yang bisa ada?

Tidak ada batas ketat yang diterapkan oleh alat ini, karena pengkodean terjadi di memori browser Anda. Batas praktisnya adalah seberapa banyak yang dapat ditampung perangkat Anda, biasanya puluhan MB tidak masalah pada laptop modern. Batasan yang lebih besar adalah dukungan konsumen: banyak klien email, browser, dan API memiliki batas ukuran URI data mereka sendiri, dan meng-inline apa pun di atas beberapa KB jarang masuk akal untuk kinerja.

Mengapa string Base64 saya 33% lebih besar dari file?

Karena setiap karakter Base64 membawa 6 bit, sementara setiap byte input membawa 8 bit. Unit terkecil yang dapat direpresentasikan Base64 tanpa sisa adalah 3 byte (24 bit = empat karakter 6-bit), sehingga rasio output adalah tepat 4/3 ≈ 1,33. Tidak ada varian Base64 yang menghindari ini, hal itu secara matematis tertanam dalam pengkodean.

Apakah gambar yang dikodekan berfungsi di email HTML?

Sebagian besar, tetapi tidak selalu. Apple Mail, Gmail modern, dan sebagian besar klien webmail merender gambar data: dengan bersih. Desktop Microsoft Outlook secara historis memiliki dukungan yang tidak konsisten, beberapa versi merender URI data dengan baik, yang lain menghapusnya sama sekali. Uji di daftar klien target Anda sebelum mengandalkan gambar Base64 dalam email transaksional. Untuk kompatibilitas luas, URL gambar yang di-host masih menjadi pilihan yang lebih aman.

Haruskah saya menggunakan base64url (dengan - dan _)?

Hanya jika Anda meletakkan data yang dikodekan dalam URL atau nama file di mana + dan / perlu di-percent-encode. Untuk atribut HTML <img src> dan nilai CSS background-image, alfabet standar berfungsi. RFC 4648 §5 mendefinisikan varian URL-safe secara eksplisit untuk kasus URL/nama file tersebut, dan memperingatkan bahwa varian itu «should not be referred to as only 'base64'» untuk menghindari kebingungan dengan alfabet standar.

Alat terkait