Encoder dan Decoder Base64

Base64 mengubah 3 byte menjadi 4 karakter

Encode Base64 mengelompokkan data per 3 byte (24 bit), membagi tiap kelompok menjadi empat bagian 6 bit, lalu menulis nomor 0–63 sebagai salah satu dari 64 karakter: A–Z, a–z, 0–9, +, dan /. Karena itu, 3 byte selalu menjadi 4 karakter, dan hasilnya sekitar 33% lebih panjang daripada data aslinya. Teks lebih dulu diubah menjadi byte UTF-8, sehingga 'Halo, apa kabar? 👋' berukuran 21 byte dan menjadi 28 karakter Base64 tanpa padding: SGFsbywgYXBhIGthYmFyPyDwn5GL. Base64 bukan enkripsi, jadi siapa pun bisa mengembalikannya begitu saja.

Pada alat di atas, kolom teks asli maupun kolom Base64 bisa diedit. Jika Anda mengubah teks asli, hasilnya di-encode; jika Anda menempelkan nilai ke kolom Base64, nilai itu di-decode. Nilai yang berbungkus, seperti header Authorization: Basic, subjek email =?UTF-8?B?…?=, alamat data:, sertifikat PEM, atau -EncodedCommand PowerShell, juga langsung dibaca setelah bungkusnya dilepas. Byte yang tidak terbaca sebagai UTF-8 dikenali sebagai pengodean lain seperti Windows-1252 atau UTF-16, atau sebagai berkas seperti PNG dan PDF. Jalur pembacaan menampilkan tahap yang dilalui konversi, sedangkan rel kelompok dan kaca pembesar menampilkan posisi 3 byte menjadi 4 karakter.

Kapan Anda perlu membaca atau membuat Base64 sendiri

• Memeriksa header HTTP Basic auth: RFC 7617 menetapkan bahwa nama pengguna, titik dua (:), dan kata sandi digabung lalu di-encode dengan Base64 dan dikirim setelah Authorization: Basic. Misalnya admin:1234 menjadi YWRtaW46MTIzNA==. Artinya, siapa pun yang melihat header ini bisa membaca kata sandinya, sehingga Basic auth hanya boleh dipakai lewat HTTPS.
• Subjek email tampak seperti =?UTF-8?B?…?=: Header email hanya boleh berisi karakter ASCII, sehingga subjek yang memuat emoji atau huruf non-ASCII ditulis dalam bentuk encoded-word menurut RFC 2047. Misalnya 'Pesanan Anda sudah dikirim 📦' menjadi =?UTF-8?B?UGVzYW5hbiBBbmRhIHN1ZGFoIGRpa2lyaW0g8J+Tpg==?=. UTF-8 di antara tanda tanya adalah pengodean karakter, sedangkan B menandakan Base64. Jika seluruh nilai header ditempelkan, alat ini membacanya dengan pengodean yang tertulis.
• Membaca konfigurasi atau Kubernetes Secret: Nilai pada kolom data di Kubernetes Secret harus berupa string yang di-encode dengan Base64; jika tidak ingin meng-encode, gunakan kolom stringData. Alat ini membantu memeriksa isi nilai yang Anda ambil atau membuat Base64 untuk nilai baru.
• Menyisipkan gambar atau PDF ke dalam JSON: Base64 sering dipakai untuk memasukkan byte berkas ke format yang hanya menerima teks. Jika nilai yang ditempelkan di kolom Base64 bukan teks, alat ini menampilkan format dan ukurannya, lalu Anda bisa menyimpannya sebagai berkas.
• Melihat isi JWT: Setiap bagian JWT yang dipisah titik (.) adalah Base64url (RFC 7515), yaitu memakai karakter URL-safe dan membuang = di akhir. Header dan payload bisa di-decode di sini, tetapi tanda tangannya tidak diperiksa.
• Membuat atau memeriksa nilai -EncodedCommand PowerShell: Dokumentasi PowerShell menyebut nilai ini harus berupa Base64 dari string UTF-16LE. Get-Date yang sama menjadi R2V0LURhdGU= dalam UTF-8, tetapi RwBlAHQALQBEAGEAdABlAA== dalam UTF-16LE, jadi hasilnya sama sekali berbeda.
• Menangani berkas sertifikat atau kunci (PEM): Isi di antara -----BEGIN CERTIFICATE----- adalah Base64 yang dipotong menjadi 64 karakter per baris sesuai RFC 7468. Jika isinya di-decode, hasilnya adalah byte berformat DER.

Cara memakai

1. Encode: Masukkan teks ke kolom teks asli, atau pilih berkas lewat 'Pilih berkas'. Anda juga bisa menyeret atau menempelkan berkas ke kolom teks asli. Hasilnya langsung muncul di kolom Base64.
2. Decode: Tempelkan nilai ke kolom Base64. Tanda kutip atau nama header di depan dan belakangnya tidak masalah. Teks muncul di kolom teks asli; jika bukan teks, muncul kartu berkas yang memuat format dan ukurannya.
3. Memilih bentuk: Di panel pengaturan, pilih standar (+ /) atau URL-safe (- _), memakai atau tanpa =, serta satu baris, 76 karakter, atau 64 karakter per baris. Bentuk nilai yang ditempelkan langsung tercermin di panel, sehingga teks hasil decode yang Anda ubah akan di-encode lagi dalam bentuk yang sama.
4. Pengodean karakter: Bawaannya adalah deteksi otomatis. Jika teks hasil decode tampak aneh, pilih sendiri UTF-8, Windows-1252, UTF-16LE, atau pengodean lain. Jika ada beberapa nilai dengan satu nilai per baris, aktifkan 'Tiap baris terpisah'.
5. Pemeriksaan: Di jalur pembacaan, periksa bungkus yang dilepas, spasi yang diabaikan, dan padding yang dilengkapi. Tekan sebuah kelompok di rel untuk melihat bitnya di kaca pembesar. Jika hasilnya berbeda dari alat lain, cari penyebabnya di daftar 'Teks sama, Base64 berbeda'; tekan barisnya untuk menyalin nilainya.

Aturan 3 byte menjadi 4 karakter

Ambil contoh 'Ibu', yang byte UTF-8-nya 49 62 75. Tiga byte digabung menjadi 24 bit, lalu dipotong per 6 bit sehingga muncul empat nomor antara 0 dan 63. Cari nomor itu di tabel karakter di bawah, dan hasilnya adalah SWJ1.

Jika data di akhir tidak habis dibagi 3 byte, bit yang kurang diisi 0 untuk membentuk karakter, dan posisi kosongnya ditulis dengan =. Sisa 1 byte menghasilkan 2 karakter dan ==, sedangkan sisa 2 byte menghasilkan 3 karakter dan =. RFC 4648 menetapkan bahwa encoder mengisi bit tambahan dengan 0, dan decoder boleh menolak nilai yang bukan 0.

Menghitung panjang Base64

Dengan padding, panjang Base64 adalah 4 × ⌈n ÷ 3⌉ (n = jumlah byte); tanpa padding, panjangnya ⌈4n ÷ 3⌉. Yang menentukan panjang adalah jumlah byte, bukan jumlah karakter. Huruf biasa memakai 1 byte per karakter dalam UTF-8, tetapi emoji memakai 4 byte dan huruf beraksen seperti é memakai 2 byte, sehingga teks dengan jumlah karakter sama bisa menghasilkan Base64 yang lebih panjang. Jika kita menyisipkan baris baru CRLF setiap 76 karakter seperti pada email, setiap baris bertambah 2 karakter.

Perbedaan standar, URL-safe, MIME, dan PEM

Namanya berbeda, tetapi perhitungan yang mengubah 3 byte menjadi 4 karakter tetap sama. Perbedaannya hanya tiga: karakter nomor 62 dan 63, tanda = di akhir, dan pemotongan baris.

Aturan decode juga sedikit berbeda. RFC 4648 menetapkan agar karakter di luar alfabet ditolak, sedangkan RFC 2045 untuk email menetapkan agar baris baru dan karakter di luar tabel diabaikan. Fungsi atob() di browser hanya membuang spasi dan memberi galat jika ada - atau _ (WHATWG forgiving-base64). Alat ini mengabaikan baris baru dan spasi, mengembalikan %2B, %2F, dan %3D dari URL serta penulisan \n dari JSON ke karakter aslinya, dan menerima karakter standar maupun URL-safe. Jika menemukan karakter lain, alat berhenti sambil menunjukkan posisinya.

Teks sama, Base64 berbeda menurut pengodean karakter

Base64 hanyalah cara menulis byte sebagai karakter, sehingga hasilnya bergantung pada byte yang dihasilkan dari teks (pengodean karakter). Teks ASCII seperti Hello menghasilkan byte yang sama di UTF-8 dan Windows-1252, sehingga Base64-nya sama. Namun huruf beraksen seperti é berbeda: 1 byte di Windows-1252 tetapi 2 byte di UTF-8. Jika byte UTF-8 dibaca sebagai Windows-1252, 'café' tampil sebagai 'café'. Inilah contoh khas teks yang rusak karena salah pengodean.

Deteksi otomatis lebih dulu memeriksa byte awal untuk melihat apakah itu tanda tangan berkas seperti PNG atau JPEG. Setelah itu, deteksi mencoba berurutan: ① nilai yang pengodeannya tertulis atau sudah ditetapkan, seperti subjek email, alamat data:, dan PowerShell; ② BOM di awal (EF BB BF, FF FE, FE FF); ③ pola UTF-16 yang menyisipkan 00 di sela karakter ASCII; ④ UTF-8, lalu memakai hasil pertama yang terbaca tanpa karakter kontrol. Jika semuanya gagal, byte dibaca sebagai EUC-KR, Shift_JIS, Windows-1252, dan UTF-16 tanpa byte 00, lalu dipilih hasil yang paling banyak berisi huruf khas pengodean itu (Hangul, kana dan kanji, huruf Latin beraksen). Jika nilainya sama, pengodean bahasa halaman didahulukan (Windows-1252 untuk halaman bahasa Indonesia). Byte saja tidak cukup untuk memastikan pengodean, jadi jika hasilnya terasa janggal, pilih sendiri di panel pengaturan.

Bungkus pada nilai tempelan yang dilepas alat ini

Nilai yang Anda salin sering memiliki nama header atau penanda bentuk di depan dan belakang Base64. Bentuk di bawah ini dilepas bungkusnya, hanya Base64 di dalamnya yang dibaca, dan jika teks asli diubah, hasilnya dibungkus kembali dengan cara yang sama (kecuali JWT yang butuh tanda tangan). Tombol × pada chip 'Bungkus dipertahankan' di jalur pembacaan dapat membuang bungkus tersebut.

Jika tidak bisa di-decode: penyebab tiap galat

Jika nilai di kolom Base64 tidak terbaca, baris status menampilkan karakter ke berapa yang menghentikan pembacaan beserta karakter di sekitarnya. Kolom teks asli tetap tampil pudar dan memperlihatkan hasil terakhir yang berhasil dibaca.

Jika hasilnya berbeda dari alat lain

Jika Anda memasukkan teks yang sama tetapi Base64-nya berbeda, hampir selalu byte-nya berbeda atau pengaturan bentuknya berbeda. Daftar 'Teks sama, Base64 berbeda' di bawah alat menghitung ulang kasus berikut dengan teks asli Anda sekarang, lalu menampilkannya mulai dari perbedaan pertama.

Melakukannya lewat kode

btoa() di browser memberi InvalidCharacterError jika ada karakter yang tidak muat dalam satu byte, misalnya emoji. Teks harus diubah dulu menjadi byte UTF-8 sebelum di-encode. Uint8Array.prototype.toBase64() yang baru dapat dipakai mulai Chrome 140, Firefox 133, dan Safari 18.2.

// JavaScript: ubah teks menjadi byte UTF-8 lalu encode (teks pendek)
const bytes = new TextEncoder().encode('Halo, apa kabar? 👋');
const b64 = btoa(String.fromCharCode(...bytes));          // SGFsbywgYXBhIGthYmFyPyDwn5GL
const back = new TextDecoder().decode(Uint8Array.from(atob(b64), c => c.charCodeAt(0)));
bytes.toBase64({ alphabet: 'base64url', omitPadding: true }); // API baru

# Python
import base64
base64.b64encode('Halo, apa kabar? 👋'.encode('utf-8'))   # b'SGFsbywgYXBhIGthYmFyPyDwn5GL'
base64.b64decode('SGVsbG8')                      # jika berakhir tanpa =, muncul binascii.Error: Incorrect padding
base64.b64decode('Zm9v-_', validate=True)        # galat, bukan membuang karakter di luar alfabet

# Baris perintah
printf '%s' 'Halo' | base64    # echo menambahkan baris baru di akhir
base64 -w 0 laporan.pdf        # GNU: tanpa pemotongan baris (base64 macOS bawaannya satu baris, -b 76 untuk memotong)

Kesalahan yang sering terjadi

• Menganggap Base64 sebagai enkripsi: Tanpa kunci pun, siapa saja bisa mengembalikannya. Kata sandi atau token yang diubah ke Base64 tidak menjadi tersembunyi.
• Memakai nilai dari echo apa adanya: echo menambahkan baris baru di akhir sehingga ujung hasilnya berubah menjadi K atau o=. Gunakan printf '%s' atau echo -n.
• Mengubah huruf besar dan kecil: Base64 membaca huruf besar dan kecil sebagai karakter yang berbeda. Jika diubah demi keseragaman penulisan, datanya menjadi lain atau tidak bisa di-decode.
• Menaruh Base64 standar langsung di query URL: Dalam pembacaan data formulir, + berubah menjadi spasi, dan / serta = juga punya arti di dalam URL. Pakai URL-safe atau lakukan percent-encoding.
• Meng-encode dua kali: Jika hasil decode terlihat seperti Base64 lagi, tombol 'Decode sekali lagi' muncul di samping baris status.
• Lupa awalan data: pada gambar Base64: Untuk HTML atau CSS, awalan data:image/png;base64, diperlukan. Untuk gambar, konverter gambar ↔ Base64 bahkan membuatkan bentuk HTML dan CSS-nya.

Batasan

• Berkas yang bisa dimasukkan maksimal 5 MB (sekitar 7 juta karakter dalam Base64). Jika teks di kolom melebihi 400.000 karakter, hanya awal dan akhirnya yang ditampilkan, sedangkan penyalinan dan penyimpanan memakai seluruh isi.
• Deteksi otomatis adalah perkiraan dari pola byte. Nilai yang pendek bisa terbaca dengan beberapa pengodean, sehingga hasilnya bisa keliru.
• Pengodean yang bisa dipakai untuk membuat hasil adalah UTF-8, UTF-16LE dan BE, EUC-KR(CP949), Shift_JIS, serta Windows-1252. Pengodean seperti ISO-2022-JP pada subjek email hanya dibaca; jika teks hasil decode diubah, hasilnya dibuat ulang dengan UTF-8.
• Tanda tangan JWT tidak diperiksa, dan encoding Q pada subjek email (=?…?Q?…?=) tidak di-decode.
• Kolom teks di browser mengubah baris baru menjadi LF, jadi baris baru di kolom teks asli di-encode sebagai LF. Jika perlu CRLF, salin baris CRLF dari 'Teks sama, Base64 berbeda'.
• Rel kelompok hanya menggambar 480 kelompok pertama (1.440 byte). Sisanya tetap ikut dikonversi dan disalin.
• Konversi hanya berjalan di dalam browser ini. Nilai yang Anda masukkan tidak dikirim ke server dan tidak disimpan di URL maupun penyimpanan.

Sumber

Acuan: Bentuk Base64 mengacu pada RFC 4648; pemakaian pada email, PEM, header autentikasi, dan JWT mengacu pada RFC masing-masing; perilaku browser mengacu pada standar WHATWG dan MDN; perilaku baris perintah dan bahasa pemrograman mengacu pada dokumentasi masing-masing. Semuanya dicek pada 21 Oktober 2026. Nilai pada tabel sudah dicocokkan dengan alat ini dan modul base64 Python 3.14, dan hasilnya sama.

• 01RFC 4648 — The Base16, Base32, and Base64 Data Encodings3.1 baris baru, 3.3 penolakan karakter di luar alfabet, 3.5 bit sisa adalah 0, bagian 4 tabel karakter, bagian 5 URL-safe (- _), bagian 10 nilai uji
• 02RFC 2045 — MIME Part One6.8 maksimal 76 karakter per baris, baris baru dan karakter di luar tabel diabaikan decoder
• 03RFC 2047 — MIME Part Three: Message Header ExtensionsBentuk encoded-word =?charset?B?…?=, maksimal 75 karakter per kata, B = BASE64
• 04RFC 7468 — Textual Encodings of PKIX StructuresIsi PEM dipotong 64 karakter per baris, kecuali baris terakhir
• 05RFC 7617 — The 'Basic' HTTP Authentication SchemeNama pengguna + ':' + kata sandi dalam Base64, nilai charset hanya UTF-8
• 06RFC 7515 — JSON Web Signature (JWS)Bagian 2 Base64url: karakter URL-safe, = di akhir dibuang, tanpa baris baru
• 07RFC 2397 — The "data" URL schemedata: + jenis media + ;base64 opsional + koma + data
• 08WHATWG Infra — forgiving-base64 decodeAturan atob(): spasi dibuang, 1 sampai 2 tanda = di akhir diizinkan, karakter selain + / gagal
• 09WHATWG — Encoding StandardPenafsiran UTF-8, UTF-16, EUC-KR, Shift_JIS, dan Windows-1252 oleh TextDecoder
• 10MDN — Window.btoa()Karakter yang tidak muat dalam satu byte menyebabkan InvalidCharacterError
• 11MDN — Uint8Array.prototype.toBase64()Opsi alphabet (base64 dan base64url) dan omitPadding; versi yang didukung ada di data kompatibilitas browser MDN
• 12Python 3 — base64 moduleb64decode(validate=False) membuang karakter di luar alfabet, urlsafe_b64encode
• 13GNU coreutils — base64(1)Bawaan -w (--wrap) adalah 76 karakter, 0 berarti tanpa pemotongan baris
• 14Microsoft Learn — about_PwshNilai -EncodedCommand adalah Base64 dari string UTF-16LE
• 15Kubernetes — SecretsNilai pada kolom data berupa Base64, gunakan stringData jika tidak ingin meng-encode

Pertanyaan yang sering diajukan

Alat yang dipakai bersama