Encoder dan Decoder Base64

Tempel string Base64 ke kotak masukan dan hasilnya langsung muncul di tab yang sama, tanpa tombol, tanpa akun, dan tanpa mengunggah apa pun. Kalau string-nya tersimpan sebagai berkas, buka saja .txt atau .b64 alih-alih menempel. Decoder membaca alfabet standar (+ /) maupun URL-safe (- _), melewati ganti baris dan spasi yang ikut tersalin, lalu menampilkan panjang hasil dalam byte di samping teksnya.

Pindah ke sisi enkode, ketik atau tempel teks Anda, dan keluaran Base64 dibuat dengan padding baku secara otomatis. Teks diubah dulu menjadi byte UTF-8, sehingga huruf beraksen dan emoji kembali utuh setelah bolak-balik. Pilih alfabet URL-safe bila string harus masuk ke dalam URL atau nama berkas, dan matikan padding bila sistem penerima menolak tanda sama dengan di ujung.

Tidak. Apa yang Anda tempel tidak keluar dari tab ini, karena proses dekode berjalan sepenuhnya di halaman yang sudah dimuat dan tidak membuat satu pun permintaan jaringan. Ini penting untuk bahan yang biasanya didekode orang — token sesi, potongan log, dan kredensial di berkas konfigurasi — yang sering memang tidak boleh ditempel ke layanan jarak jauh.

Bisa. Setelah halaman termuat, Anda boleh memutus koneksi dan tetap mendekode maupun mengenkode, dan tidak ada permintaan pendaftaran atau email sama sekali. Selama proses dekode tidak ada yang diunduh, jadi komputer tanpa internet berperilaku persis sama dengan yang terhubung. Yang butuh koneksi hanya pemuatan halaman pertama, maka biarkan tab terbuka bila jaringan akan hilang.

Buka halaman ini di Chrome pada HP Android, ketuk pemilih berkas, lalu pilih file .b64 dari penyimpanan — tidak ada aplikasi yang perlu dipasang. Cara ini menolong karena pengelola berkas bawaan Android umumnya tidak mengenali ekstensi .b64 dan hanya menampilkan deretan karakter tanpa arti. Hasil teks bisa langsung disalin, sedangkan hasil biner disimpan sebagai unduhan.

Karena ada karakter yang tidak termasuk dalam kedua alfabet Base64, dan pesannya menyebut karakter itu berikut indeks, baris, dan kolomnya di string persis seperti yang Anda tempel. Penyebab tersering adalah tanda kutip lengkung hasil salin dari JSON, titik-titik dari baris log yang terpotong, atau kurung sudut yang ikut tersalin dari XML. Karakter itu tidak dibuang diam-diam supaya Anda tahu sumbernya memang rusak.

Karena byte hasil dekode bukan UTF-8 yang sah, atau mengandung byte kendali yang tidak mungkin ada di berkas teks, sehingga dilaporkan sebagai biner alih-alih ditampilkan kacau. Pemeriksaannya ketat dan tidak pernah mengganti urutan rusak dengan karakter pengganti; Anda mendapat vonis apa adanya beserta offset kerusakan pertama. Bila byte-nya diawali tanda tangan gambar yang dikenal, wadahnya disebut dan berkas ditawarkan untuk diunduh.

Masukan dibatasi 2.000.000 karakter dan hasil dekode 2.000.000 byte, dan kedua batas diperiksa sebelum memori dialokasikan sama sekali. Karena itu tempelan yang kebesaran langsung ditolak dengan error ukuran yang menyebut jumlah dan batasnya, bukan membekukan tab saat menyiapkan penyangga yang mustahil terisi. Layar hanya mempratinjau 200.000 karakter dari teks panjang, sedangkan salin dan unduh tetap membawa seluruh isinya.

Ya. String yang panjangnya menyisakan dua atau tiga karakter tetap didekode normal dan hanya diberi catatan bahwa padding-nya tidak ada. Base64 tanpa padding adalah hal biasa pada JWT dan parameter URL, jadi menolaknya justru keliru. Yang ditolak adalah padding yang salah: tanda sama dengan berlebih, padding setengah jadi, data setelah padding, atau sisa satu karakter yang tidak membentuk byte utuh.

Proses dekodenya aman di sini karena muatan selalu diperlakukan sebagai byte pasif: tidak ada yang dieksekusi, HTML hasil dekode tidak dirender, dan URL di dalam hasil tidak diakses. Risikonya berpindah ke langkah berikutnya — berkas pemasang atau dokumen bermakro yang sudah didekode tetap sama berbahayanya begitu Anda simpan dan buka. Alat ini menyebutkan byte-nya apa, bukan menilai berbahaya atau tidak.

Base64 standar memakai + dan / untuk nilai 62 dan 63, sedangkan URL-safe memakai - dan _ supaya string bisa ditaruh apa adanya di dalam URL atau nama berkas. Byte hasil dekodenya sama persis, dan alat ini menerima keduanya sambil memberi tahu mana yang terdeteksi. String yang mencampur keduanya ditolak, sebab campuran itu hampir selalu menandakan dua salinan berbeda yang tersambung.

Tidak. Dekode yang mulus hanya membuktikan karakternya membentuk urutan Base64 yang benar, bukan bahwa datanya asli atau tidak pernah diubah. Base64 adalah pengodean, bukan enkripsi dan bukan tanda tangan: siapa pun bisa mengubah isinya, mengenkode ulang, dan hasilnya tetap terdekode sebersih aslinya. Kepercayaan ditentukan asal-usul berkasnya, bukan keberhasilan dekode.