Base64 Encoder & Decoder Online Gratis

Apa Itu Base64?

Base64 adalah skema encoding biner-ke-teks, cara untuk merepresentasikan urutan byte (data biner) apa pun sebagai urutan karakter ASCII biasa yang dapat melewati saluran khusus-teks tanpa kerusakan. Nama mencerminkan ukuran alfabet: 64 karakter dipilih secara khusus karena mereka bertahan transmisi 7-bit-bersih tanpa perubahan. Alfabet standar adalah A-Z (posisi 0-25), a-z (26-51), 0-9 (52-61), kemudian + (62) dan / (63). Karakter = dicadangkan sebagai padding ketika panjang input bukan kelipatan tepat dari tiga. Setiap tiga byte input (24 bit) menjadi empat karakter output (masing-masing membawa 6 bit), itulah mengapa data yang di-encode Base64 sekitar 33% lebih besar dari aslinya.

Mekanika: ambil tiga byte (24 bit), kelompokkan ulang sebagai empat chunk 6-bit, cari setiap chunk di alfabet 64-karakter. Contoh klasik yang dikerjakan: tiga byte ASCII M a n (0x4D 0x61 0x6E) membentuk pola 24-bit 01001101 01100001 01101110; dikelompokkan ulang menjadi chunk 6-bit: 010011 010110 000101 101110 = desimal 19, 22, 5, 46 = karakter T W F u. Jadi "Man" di-encode Base64 menjadi "TWFu". Jika panjang input tidak habis dibagi tiga, encoder akan padding dengan satu atau dua karakter =: input 1 byte menghasilkan 2 karakter + ==, input 2 byte menghasilkan 3 karakter + =.

Sejarah Singkat Base64

Base64 berasal dari upaya Privacy Enhanced Mail (PEM) IETF. RFC 989 pada Februari 1987 adalah definisi formal pertama; RFC 1113 pada Agustus 1989 merevisinya; RFC 1421 pada Februari 1993 menyelesaikan spesifikasi PEM dengan encoding Base64 disertakan. Base64 memasuki arus utama email ketika spesifikasi MIME (Multipurpose Internet Mail Extensions) mengadopsinya: RFC 2045 pada November 1996 mendefinisikan Base64 sebagai encoding standar untuk lampiran email biner, itulah mengapa setiap PDF atau gambar yang pernah Anda lampirkan ke email melakukan perjalanan melintasi kabel sebagai Base64. Spesifikasi kanonik saat ini adalah RFC 4648 ("The Base16, Base32, and Base64 Data Encodings"), diterbitkan Oktober 2006 oleh Simon Josefsson, yang menggantikan RFC 3548 (Juli 2003) dan menyatukan berbagai encoding keluarga Base16 / Base32 / Base64 ke dalam satu dokumen. RFC 4648 adalah spec yang menjadi target setiap implementasi Base64 modern.

Base64 URL-Safe, Mengapa Dua Karakter Diganti

Alfabet Base64 standar menggunakan + dan /, keduanya merupakan karakter yang dicadangkan dalam URL. + dalam query string URL biasanya berarti "spasi" (konvensi form-encoded); / adalah pemisah jalur. Memasukkan Base64 standar dalam URL berarti percent-encoding keduanya, yang menggembungkan string lebih lanjut dan membuatnya jelek. RFC 4648 §5 mendefinisikan varian URL-safe: ganti + dengan - (tanda hubung-minus) dan / dengan _ (garis bawah). Kadang-kadang disebut Base64URL atau base64url. Hasilnya adalah string yang masuk langsung ke URL tanpa escape lebih lanjut, persis apa yang digunakan JWT (JSON Web Tokens), parameter state OAuth, ID kredensial WebAuthn, dan sebagian besar API web modern. Beberapa implementasi juga menghilangkan padding = trailing karena panjang implisit dari field berikutnya. Struktur tiga bagian dipisahkan titik JWT (header.payload.signature) adalah tiga segmen yang di-encode Base64URL; jika Anda pernah mendekode JWT secara manual, Anda telah melihat karakter - dan _ yang menandainya sebagai Base64URL bukan Base64 standar.

Keluarga Base-N, Base16, Base32, Base58, Base85

Base64 bukan satu-satunya encoding biner-ke-teks. Base16 (hex) menggunakan 16 karakter (0-9 dan A-F), 100% ekspansi ukuran (setiap byte menjadi 2 karakter hex), tetapi sepele dapat dibaca dan default universal untuk output hash, checksum file, dan pengidentifikasi mesin. Base32 (RFC 4648, juga varian Crockford) menggunakan 32 karakter dengan perhatian untuk mengecualikan pasangan yang ambigu secara visual seperti 0/O dan 1/I/L; 60% ekspansi ukuran; digunakan dalam kunci rahasia TOTP, ULID, dan alamat onion Tor. Base58 adalah Bitcoin-kanonik: 58 karakter tidak termasuk yang mudah bingung 0/O/I/l, ditambah karakter khusus Base64 standar +/=. Alamat Bitcoin, alamat Solana, dan banyak pengidentifikasi dompet kripto menggunakan Base58Check (Base58 ditambah checksum 4-byte). Base85 / Ascii85 mengemas kepadatan lebih (encoding 4 byte sebagai 5 karakter, hanya 25% ekspansi) tetapi menggunakan alfabet yang menyertakan tanda baca yang tidak aman untuk URL; format PostScript dan PDF Adobe menggunakan Base85 secara internal untuk data biner tertanam. Trade-off umum: lebih banyak karakter dalam alfabet berarti lebih sedikit ekspansi tetapi set karakter yang lebih terbatas; lebih sedikit karakter berarti transportasi yang lebih aman dengan biaya output yang lebih besar.

Penggunaan Umum Base64

• Lampiran email (MIME). RFC 2045 sejak 1996. Setiap PDF, gambar atau dokumen yang pernah Anda lampirkan ke email melakukan perjalanan jaringan sebagai Base64 karena SMTP awalnya adalah protokol teks bersih 7-bit yang tidak dapat menangani biner mentah.
• URI data: di HTML/CSS. data:image/png;base64,iVBORw0KGgo... menyematkan gambar kecil langsung ke dalam HTML atau stylesheet CSS, menghilangkan permintaan HTTP. Berguna untuk ikon di bawah ~10 KB; kontra-produktif untuk gambar yang lebih besar karena ekspansi Base64 33% melebihi overhead permintaan HTTP yang dihemat.
• Biner dalam payload JSON. JSON hanya teks menurut spec, tidak ada cara untuk meletakkan byte mentah dalam nilai JSON. API yang perlu mengirimkan gambar, PDF, atau biner lain menyematkannya sebagai string Base64 dalam field JSON. Payload webhook Stripe, API MMS Twilio, dan banyak endpoint AI-vision menggunakan pola ini.
• JWT (JSON Web Tokens). Tiga bagian yang dipisahkan titik dari JWT (header.payload.signature) semuanya di-encode Base64URL. Spec JWT (RFC 7519, Mei 2015) dibangun di atas JOSE (RFC 7515-7518, juga Mei 2015), semuanya mengamanatkan Base64URL di seluruhnya.
• OAuth dan OpenID Connect. Parameter state, verifier kode PKCE, token ID, dan token akses di banyak implementasi menggunakan Base64URL.
• HTTP Basic Authentication. Header Authorization: Basic dXNlcjpwYXNz membawa Base64(username:password). Catatan: ini adalah encoding untuk transportasi, BUKAN enkripsi, Basic Auth melalui HTTP biasa mengekspos kredensial dalam plaintext kepada siapa pun yang menonton jaringan. Selalu pasangkan dengan HTTPS.
• Subresource Integrity (SRI). Atribut integrity="sha384-..." pada tag <script> dan <link> membawa hash yang di-encode Base64 dari konten file yang diharapkan; browser memverifikasi file yang diunduh cocok sebelum dieksekusi.
• Latar belakang SVG-dalam-CSS. background-image: url("data:image/svg+xml;base64,...") menyematkan SVG langsung dalam stylesheet. Bentuk Base64 kadang-kadang lebih disukai daripada bentuk URL-encoded (yang membuat SVG dapat dibaca tetapi menggunakan aturan escape yang berbeda).

Encoding Bukan Enkripsi, Kesalahan Keamanan Umum

Base64 menawarkan nol keamanan. Encoding sepenuhnya dapat dibalik oleh siapa saja dalam milidetik, alfabet bersifat publik, algoritma sepele, dan setiap browser atau perintah CLI satu baris dapat mendekodenya. Meskipun demikian, "data sensitif yang di-encode Base64" adalah salah satu contoh yang paling sering dikutip dalam CWE-261 MITRE (Encoding Lemah untuk Password) dan terus muncul dalam audit keamanan: kunci API "disamarkan" oleh Base64 dalam kode klien; password "di-encode" dengan Base64 dalam file backup database; rahasia "dienkripsi" dengan Base64 sebelum dikomit ke repositori Git publik. Tidak satu pun dari ini yang dilindungi. Jika Anda memerlukan kerahasiaan yang sebenarnya, gunakan enkripsi nyata: AES-256-GCM untuk simetris, RSA-OAEP atau ECDH+ChaCha20-Poly1305 untuk asimetris. Base64 cocok untuk transportasi (mengubah biner menjadi bentuk yang ramah teks) tetapi tidak pernah untuk perlindungan.

Implementasi Browser: btoa / atob dan Jebakan Unicode

JavaScript mengekspos dua fungsi global bawaan untuk Base64: btoa() (binary-to-ASCII, encode) dan atob() (ASCII-to-binary, decode). Keduanya adalah API legacy dari era Netscape awal dan memiliki batasan yang terkenal: mereka hanya bekerja pada string byte Latin-1. Memanggil btoa('é') menyebabkan InvalidCharacterError karena string JavaScript 'é' berisi titik kode di atas U+00FF yang tidak muat dalam byte tunggal. Perbaikan modern adalah meng-encode ke byte UTF-8 terlebih dahulu melalui TextEncoder, kemudian mengonversi Uint8Array yang dihasilkan menjadi string Latin-1 untuk konsumsi btoa(). Polanya: btoa(String.fromCharCode(...new TextEncoder().encode(str))). Mendekode kebalikannya: new TextDecoder().decode(Uint8Array.from(atob(str), c => c.charCodeAt(0))). Browser yang lebih baru mengekspos Uint8Array.toBase64() dan Uint8Array.fromBase64() sebagai metode bawaan, tetapi adopsi masih bergulir per 2026, polyfill melalui btoa/atob tetap menjadi default cross-browser. Untuk file secara khusus, FileReader.readAsDataURL() adalah jalur paling sederhana: jatuhkan file ke dalam input, reader mengembalikan string data:mime/type;base64,... dengan semuanya di-encode dengan benar; lepaskan awalan data: untuk mendapatkan hanya bagian Base64.

Lingkup Jujur: Apa yang Dilakukan dan Tidak Dilakukan Alat Ini

Alat ini meng-encode teks atau file (hingga 5 MB) ke Base64 dan mendekode string Base64 kembali ke teks atau file yang dapat diunduh. Menggunakan alfabet standar RFC 4648 (dengan + dan /) secara default; Base64URL URL-safe (dengan - dan _) adalah toggle fitur masa depan. Teks UTF-8 ditangani dengan benar melalui TextEncoder, jebakan btoa-Latin-1 diperbaiki. Batas ukuran file 5 MB ada karena Base64 memperluas data sebesar 33% dan string yang di-encode hidup sepenuhnya di memori browser; file biner 5 MB menghasilkan ~6,7 MB teks Base64 ditambah buffer asli, yang bekerja di setiap perangkat modern. Untuk file yang lebih besar, alternatif standar adalah base64 command-line di macOS/Linux (base64 -i input.bin -o output.txt), modul base64 Python, atau Buffer.from(data).toString('base64') Node.js. Alat ini tidak menangani: Base64 streaming (encoding file-per-chunk untuk file yang lebih besar dari memori); varian URL-safe di versi ini (direncanakan); juga tidak encoding MIME quoted-printable (skema RFC 2045 yang berbeda untuk konten email teks).

Privasi: Mengapa Browser-Saja Penting

Base64 bukan enkripsi, tetapi data yang di-encode sering kali sensitif: kunci API yang Anda sematkan dalam file config, sertifikat yang Anda encode untuk transportasi, screenshot internal yang Anda sematkan sebagai URI data di dokumentasi, atau kuitansi PDF yang Anda encode untuk klien. Encoder sisi server melihat input Anda. Alat ini berjalan sepenuhnya di browser Anda melalui JavaScript, verifikasi di tab Network DevTools saat Anda mengklik Encode, atau bawa halaman offline (mode pesawat) setelah dimuat dan alat masih bekerja. Aman untuk meng-encode kredensial API, screenshot PII, dokumen internal, atau data apa pun yang tidak ingin Anda salin ke hard drive orang asing.

Pertanyaan yang Sering Diajukan

Apakah Base64 aman?

Tidak. Base64 adalah encoding, bukan enkripsi. Siapa pun dapat men-decode string Base64. Jangan pernah menggunakan Base64 untuk melindungi data sensitif, gunakan enkripsi yang tepat (AES, RSA) untuk keamanan.

Mengapa Base64 membuat file lebih besar?

Encoding Base64 meningkatkan ukuran data sekitar 33%. Tiga byte data biner menjadi empat karakter Base64. Overhead ini adalah kompromi untuk dapat mengirimkan data biner sebagai teks.

Bisakah saya meng-encode file?

Ya! Seret dan letakkan file apa pun ke encoder, atau klik untuk menelusuri. File akan dikonversi ke Base64 data URI yang dapat Anda tempel langsung ke HTML, CSS, atau JavaScript.

Apa perbedaan antara Base64 dan Base64URL?

Dua karakter. Base64 standar (RFC 4648 §4) menggunakan + dan / sebagai karakter alfabet ke-62 dan ke-63. Base64URL URL-safe (RFC 4648 §5) menggunakan - dan _ sebagai gantinya, jadi string yang di-encode masuk langsung ke URL tanpa percent-encoding. JWT, OAuth, WebAuthn, dan sebagian besar API web modern menggunakan Base64URL. Alat ini saat ini mengeluarkan Base64 standar; URL-safe ada di daftar fitur masa depan. Untuk mengonversi standar ke URL-safe secara manual: ganti + dengan -, / dengan _, opsional jatuhkan padding = trailing.

Mengapa teks Unicode saya gagal di beberapa alat Base64?

Karena fungsi legacy btoa() JavaScript hanya bekerja pada string byte Latin-1, memanggil btoa('é') menyebabkan InvalidCharacterError. Banyak encoder berbasis browser lama menggunakan btoa secara langsung tanpa langkah konversi UTF-8, jadi input non-ASCII apa pun rusak. Kode modern (dan alat ini) meng-encode string melalui TextEncoder terlebih dahulu, menghasilkan urutan byte UTF-8 yang kemudian dapat di-encode btoa dengan aman. Metode bawaan baru Uint8Array.toBase64() menangani UTF-8 secara native tetapi belum baseline di semua browser.

Apakah data saya diunggah?

Tidak. Encoding dan decoding berjalan sepenuhnya di browser Anda melalui JavaScript. Teks dan file tidak pernah melintasi jaringan, verifikasi di tab Network DevTools saat Anda mengklik Encode, atau bawa halaman offline (mode pesawat) setelah dimuat dan alat masih bekerja. Aman untuk kredensial API, screenshot yang membawa PII, file config internal, atau data apa pun yang tidak ingin Anda salin ke hard drive orang asing.

Alat Terkait