Encoder File Base64 Gratis
Konversi file apa pun menjadi Base64 data URL · semuanya tetap di browser Anda.
Seret dan lepas file di sini
atau
Pilih atau lepas file untuk dienkode.
Cara Kerja
- Unggah file Anda: Letakkan file apa pun, gambar, PDF, font, audio, atau biner, ke zona lepas atau klik untuk menelusuri.
- Dapatkan string Base64: File dibaca dan dienkode ke Base64 secara instan di browser Anda.
- Salin dan gunakan: Salin string Base64 untuk disematkan di HTML, CSS, payload JSON, data URI, atau format berbasis teks apa pun.
Mengapa Menggunakan Encoder File Base64?
File biner tidak dapat disematkan langsung dalam format berbasis teks seperti HTML, CSS, JSON, atau XML. Encoding Base64 mengonversi file biner apa pun menjadi string ASCII yang aman yang dapat disematkan di mana saja teks diizinkan. Ini penting untuk menyematkan gambar di HTML (data URI), menyertakan font di CSS, mengirim file melalui email atau JSON API tanpa endpoint unggah, dan membuat dokumen HTML mandiri.
Fitur
- Semua jenis file: Mengenkode gambar, PDF, font, audio, video, dan semua file biner.
- Output data URI: Aktifkan untuk mendapatkan data URI siap pakai (data:mime/type;base64,...) untuk penyematan langsung.
- Tampilan ukuran file: Menampilkan ukuran asli dan terenkode sehingga Anda tahu overhead-nya.
- Pemrosesan lokal: File dibaca dan dienkode sepenuhnya di browser Anda, tidak ada yang diunggah.
Pertanyaan yang Sering Diajukan
Seberapa besar Base64 dibanding file asli?
Encoding Base64 meningkatkan ukuran file sekitar 33%. Gambar 100 KB menjadi sekitar 133 KB saat dienkode Base64. Overhead ini adalah pertukaran untuk dapat menyematkan konten biner dalam teks.
Bisakah saya menggunakan gambar Base64 di HTML?
Ya. Gunakan data URI seperti 
. Ini menyematkan gambar langsung di HTML tanpa permintaan HTTP eksternal, meskipun meningkatkan ukuran halaman.
Apakah ada batas ukuran file?
Alat ini tidak memiliki batas yang dipaksakan, tetapi file yang sangat besar (di atas 10 MB) mungkin lambat dienkode dan string yang dihasilkan akan sangat panjang. Untuk file besar, pertimbangkan solusi sisi server.
Dari mana Base64 berasal, dan mengapa kita masih menggunakannya
Base64 dirancang untuk membawa data biner 8-bit melalui pipa ASCII 7-bit. Spesifikasi formal pertama adalah RFC 989 (Februari 1987) untuk Privacy-Enhanced Mail. RFC 1341 (Juni 1992) dan terutama RFC 2045 «MIME Bagian Satu» (November 1996) menjadikannya cara standar untuk melampirkan file biner ke email. Dokumen kanonik saat ini adalah RFC 4648 (Oktober 2006), yang juga mendefinisikan varian URL-safe. Mekanismenya sederhana: ambil 3 byte input (24 bit), bagi menjadi empat grup 6-bit, cari masing-masing dalam alfabet 64 karakter A-Z a-z 0-9 + /, tambahkan padding = untuk membuat panjang output kelipatan 4. Ukuran output tepat 4 ÷ 3 ≈ 133 % dari input. Untuk menyematkan dalam URL (JWT, OAuth, URL S3 pre-signed), varian URL-safe dari RFC 4648 §5 menggantikan - untuk + dan _ untuk /; padding biasanya dihilangkan.
URL data:: Base64 dalam HTML dan CSS Anda
Skema URL data: ditentukan dalam RFC 2397 (Agustus 1998). Format: data:[<mediatype>][;base64],<data>. Contoh: <img src="data:image/png;base64,iVBORw0KGgo..."> menyematkan PNG inline tanpa permintaan HTTP tambahan. WHATWG URL Living Standard mengatur bagaimana browser modern menginterpretasikan URL ini dan HTML Living Standard mengonfirmasi bahwa mereka valid di mana pun URL diperbolehkan, termasuk <img>, <link>, <iframe>, dan fungsi CSS url(). Panduan praktis: gunakan URL data untuk aset di bawah sekitar 4 KB, di mana menghemat satu permintaan HTTP mengalahkan pembengkakan payload 33 persen. Di atas 10 KB, referensi file biasa dengan caching browser hampir selalu menang, terutama dalam multiplexing HTTP/2.
API browser yang menggerakkan alat ini
Halaman ini menggunakan FileReader API dari HTML Living Standard (awalnya W3C File API First Public Working Draft November 2009; dikirim di Chrome 13 / Firefox 3.6 / Safari 6 / Internet Explorer 10). FileReader.readAsDataURL(blob) mengembalikan string lengkap data:<mime>;base64,<...> dengan satu panggilan. Alternatif lama adalah btoa() (dinamai dari perintah Unix historis «binary-to-ASCII» dan sisa JavaScript DOM Level 0), tetapi melempar pada input non-Latin-1 kecuali Anda transcode terlebih dahulu melalui UTF-8. Pengganti modern adalah Uint8Array.prototype.toBase64(), ditambahkan ke ECMAScript 2025 di TC39 Stage 4. Itu dikirim di Chrome 132 (Januari 2025), Firefox 133 (November 2024), dan Safari 18.2 (Desember 2024). Gunakan API baru untuk kode baru apa pun; cadangkan btoa untuk kompatibilitas dengan browser lama.
Ke mana output alat ini sebenarnya pergi
- Ikon inline dan gambar kecil dalam HTML / CSS untuk dokumen mandiri atau offline-first.
- Payload upload file JSON ketika backend mengharapkan string Base64 dalam field JSON daripada
multipart/form-data. - Lampiran email MIME: RFC 2045 memerlukan Base64 (atau quoted-printable) untuk setiap body non-7-bit, yang berarti setiap lampiran PDF, gambar, atau dokumen.
- Token JWT / OAuth: setiap JWT adalah tiga segmen Base64 URL-safe yang digabungkan dengan
.. - Fixture pengujian dikomitkan ke git, sehingga gambar pengujian / dokumen sampel bepergian dengan file pengujian.
- Payload Web Push ketika mengirim blob biner melalui Push API.
- Font web critical-path disematkan di CSS untuk penghindaran FOIT (flash of invisible text) pada cat pertama, trade-off diterima.
Kesalahan umum
- Memperlakukan Base64 sebagai enkripsi. Base64 adalah pengkodean, bukan keamanan. Siapa pun dengan string dapat mendekodenya di browser mereka. Jangan pernah menggunakan Base64 untuk «menyembunyikan» kredensial, kunci API, atau PII.
- Melupakan prefix
data:<mime>;base64,. String Base64 telanjang bukan URL data.<img>membutuhkan bentuk lengkapdata:image/png;base64,<base64-anda>untuk merender. - Mencampur Base64 URL-safe dan standar. JWT dan URL S3 pre-signed menggunakan URL-safe (
-dan_). Menempelkan Base64 standar (+dan/) ke dalam konteks ini menghasilkan kegagalan dekode senyap. - Melupakan direktif CSP
data:. Halaman denganimg-src 'self'di Content Security Policy-nya akan menolak memuat URLdata:image/...apa pun. Anda harus secara eksplisit mengizinkanimg-src 'self' data:(dan demikian pula untukfont-src,media-src, dll.). - Mengkodekan file 100 MB secara sinkron pada thread utama.
FileReader.readAsDataURLmemblokir UI selama beberapa detik pada file 200 MB. Untuk apa pun di atas ~20 MB, gunakan Web Worker atau chunk stream. - Memanggil
btoa("é")secara langsung. Itu melemparInvalidCharacterErrorkarenabtoamengharapkan Latin-1, bukan UTF-8. Gunakanbtoa(unescape(encodeURIComponent(text)))(lama), atau lewatkanUint8Arraymelalui metode moderntoBase64(). - Inline logo 500 KB sebagai URL data. Pembengkakan 33 persen plus kehilangan caching browser berarti setiap pemuatan halaman mengunduh 665 KB alih-alih 500 KB-sekali. Gunakan referensi aset biasa.
Pertanyaan yang lebih sering diajukan
Apa overhead ukuran Base64 yang tepat?
Tepat 4 ÷ 3 ≈ 1,333× input, ditambah 1-2 byte padding =. Input 999 byte menjadi 1332 karakter Base64 (tidak ada padding karena 999 ÷ 3 = 333 tepat). Input 1000 byte menjadi 1336 (satu byte padding). Untuk URL data, tambahkan byte prefix (mis. data:image/png;base64, adalah 23 karakter).
Bagaimana cara mendapatkan Base64 URL-safe untuk JWT atau URL S3 pre-signed?
Ambil output Base64 standar dari alat ini dan terapkan dua penggantian: + → -, / → _. JWT secara khusus menghapus padding = di akhir; S3 mempertahankannya. RFC 4648 §5 mendokumentasikan varian.
Bisakah saya round-trip file melalui Base64 tanpa korupsi?
Ya. Base64 adalah pengkodean tanpa kehilangan. Pengkodean ke Base64 lalu dekode kembali menghasilkan asli yang identik byte-per-byte. Satu-satunya cara kehilangan data adalah memotong string Base64 (mis. membatasi karakter di penyimpanan Anda) atau membingungkan alfabet standar vs URL-safe saat decoding.
Apa ukuran file maksimum yang dapat ditangani alat ini?
Tidak ada batas keras; dalam praktik memori browser adalah langit-langit. Mengkodekan file 100 MB membutuhkan sekitar 100 MB input ditambah 133 MB output, ditambah overhead DOM untuk string hasil, mungkin total 400 MB. Di seluler, harapkan kegagalan di atas sekitar 30 MB. Pengkodean berjalan di thread utama, jadi UI membeku selama pemrosesan; untuk file di atas 20 MB, solusi sisi server atau Web Worker lebih nyaman.
Apakah file saya diunggah ke mana pun?
Tidak. File dibaca dengan API FileReader.readAsDataURL browser, yang berjalan sepenuhnya di browser Anda. Tidak ada permintaan jaringan yang dibuat dan tidak ada salinan file Anda yang disimpan di server mana pun. Buka tab Jaringan di DevTools dan jatuhkan file: Anda akan melihat nol permintaan keluar selama pengkodean.