Base64 vs URL encoding: apa perbedaannya?

“Encoding Base64” dan “URL encoding” terdengar seperti dua hal yang serupa — keduanya mengonversi data menjadi representasi lain yang hanya menggunakan karakter aman. Tapi masalah yang mereka selesaikan berbeda, output yang dihasilkan sangat berbeda, dan konteks penggunaannya pun berbeda. Mencampuradukkan keduanya adalah resep ampuh untuk merusak API, mengacaukan link, dan membuang berjam-jam dalam sesi debugging yang frustrasi.

Mari kita luruskan.

Dua encoding sekilas

	Base64	URL encoding (percent-encoding)
Tujuan	Merepresentasikan data biner sebagai teks	Membuat string aman untuk URL
Alfabet	64 karakter (A-Z, a-z, 0-9, +, /)	ASCII yang dapat dicetak, menggunakan %XX untuk karakter tidak aman
Peningkatan ukuran	Tepat +33%	Bervariasi (biasanya +0-200% tergantung konten)
Digunakan di	Email, JSON, data URI, JWT	URL, pengiriman form, query string
Input	Byte	Teks (biasanya string yang berisi karakter khusus)

Apa yang sebenarnya dilakukan URL encoding

URL encoding (secara formal percent-encoding, didefinisikan dalam RFC 3986) adalah skema yang memungkinkan Anda meletakkan teks sembarang ke dalam URL tanpa merusaknya.

URL memiliki struktur:

https://example.com/search?q=coffee&lang=en

Karakter tertentu memiliki arti khusus:

• ? memisahkan path dari query string
• & memisahkan parameter query
• = memisahkan key dari value
• / memisahkan segmen path
• # memulai fragment

Jika Anda ingin menyertakan salah satu karakter tersebut sebagai data (misalnya query untuk “A & B”), Anda perlu meng-escape mereka sehingga parser URL tidak bingung. URL encoding melakukan ini dengan mengganti setiap karakter khusus dengan % diikuti dengan kode ASCII heksadesimal dua digitnya:

• Spasi → %20 (atau kadang + dalam query string)
• & → %26
• = → %3D
• # → %23

Jadi A & B menjadi A%20%26%20B (atau A+%26+B dalam query string).

URL encoding hanya mempengaruhi karakter yang perlu di-escape; karakter aman (huruf, angka, -, _, ., ~) melewatkan tanpa tersentuh. Untuk input yang sebagian besar sudah karakter aman, outputnya hanya sedikit lebih panjang. Untuk input yang penuh dengan karakter khusus (kutip, garis miring, non-ASCII), outputnya bisa jauh lebih panjang.

Apa yang sebenarnya dilakukan Base64

Base64 sama sekali berbeda. Ia mengambil byte (tidak harus teks) dan menghasilkan teks yang hanya menggunakan 64 karakter dalam alfabetnya. Setiap 3 byte input menjadi 4 karakter output, selalu.

Base64 tidak peduli apa inputnya. Ia memperlakukan semuanya sebagai byte dan menghasilkan string yang aman diletakkan hampir di mana saja teks diharapkan. Outputnya tepat 33% lebih panjang daripada input (ditambah padding ke 4 karakter terdekat dengan =).

Base64 adalah pilihan utama saat Anda perlu meletakkan data biner (gambar PNG, file zip, blob terenkripsi) melalui saluran teks saja seperti email atau JSON. URL encoding tidak benar-benar dapat melakukan itu - ia dirancang untuk transformasi teks-ke-teks, bukan biner sembarang.

Tumpang tindih: kapan Anda membutuhkan keduanya

Ada satu skenario spesifik di mana kedua encoding muncul: meletakkan data biner dalam URL.

Katakanlah Anda memiliki gambar kecil (20 byte PNG) dan Anda ingin menanamkannya dalam URL sebagai parameter:

1. Base64-encode gambar → Anda mendapatkan string 28 karakter
2. URL-encode string Base64 → karakter +, /, dan = menjadi %2B, %2F, %3D

URL akhir sedikit lebih panjang daripada string Base64, tetapi sekarang aman digunakan dalam URL apa pun.

Karena kombinasi ini sangat umum, varian yang disebut Base64 URL-safe ada. Ia menggunakan - dan _ alih-alih + dan / (yang aman dalam URL tanpa escaping), dan biasanya menjatuhkan padding =:

• Base64 standar: a+b/c=
• Base64 URL-safe: a-b_c

JWT (JSON Web Tokens) menggunakan Base64 URL-safe, itulah mengapa Anda melihat string seperti eyJhbGciOiJIUzI1NiJ9 tanpa karakter + atau / apa pun.

Contoh berdampingan

Input: teks Hello, world! (13 byte)

URL encoding (memperlakukan seluruhnya sebagai teks, meng-escape koma, spasi, dan !):

Hello%2C%20world%21

Panjang: 19 karakter. Masih dapat dibaca.

Base64 encoding (memperlakukan 13 byte dan mengkonversi ke teks):

SGVsbG8sIHdvcmxkIQ==

Panjang: 20 karakter. Tidak dapat dibaca.

Base64 URL-safe (Base64 tanpa karakter yang perlu di-escape):

SGVsbG8sIHdvcmxkIQ

Panjang: 18 karakter. Digunakan dalam JWT dan ID kompak.

Kapan menggunakan URL encoding

Gunakan URL encoding saat menanamkan input pengguna dalam path URL atau query string — apa pun yang diketik ke kotak pencarian perlu di-encode sebelum jadi bagian dari URL. Form HTML juga mengirim data dalam bentuk URL-encoded secara default. Saat membangun URL REST API yang menyertakan parameter dinamis (username, ID dengan karakter khusus, path file), URL encoding juga yang tepat.

Jangan gunakan URL encoding untuk data biner. Ia tidak menangani byte sembarang dengan baik — apa pun di luar ASCII menjadi canggung dan boros ruang. Untuk gambar atau file, gunakan Base64 dulu (lalu URL-encode hasilnya kalau perlu).

Kapan menggunakan Base64

Base64 adalah pilihan yang tepat saat mentransmisikan data biner melalui saluran berbasis teks (JSON, email, XML), menanamkan file kecil dalam HTML atau CSS lewat data URI, bekerja dengan token, sertifikat, atau data kriptografi yang datang sebagai byte tapi perlu disimpan sebagai teks, dan saat berbagi file via copy-paste di medium yang tidak mendukung biner.

Jangan pakai Base64 kalau data sudah berupa teks dan Anda cuma perlu meng-escape karakter khusus untuk URL — itu pekerjaan URL encoding. Dan kalau ukuran data penting dan Anda punya saluran yang mendukung biner, kirim saja byte langsung daripada menambah 33% overhead.

Skenario kekeliruan umum

Kekeliruan 1: “Saya Base64-encode string untuk meletakkannya di URL, dan masih rusak”

Output Base64 mengandung +, /, dan = - semuanya memiliki arti khusus dalam URL. Anda perlu URL-encode string Base64, atau gunakan varian Base64 URL-safe (yang menggunakan - dan _ sebagai gantinya).

Kekeliruan 2: “Saya URL-encode file tetapi rusak”

URL encoding memperlakukan input sebagai teks, yang berarti byte non-ASCII ditangani secara tidak konsisten tergantung pada encoding yang diasumsikan. Untuk file biner, Anda perlu Base64 dulu, lalu URL-encode hasilnya jika perlu.

Kekeliruan 3: “API mengatakan untuk Base64-encode password untuk Basic Auth”

HTTP Basic Authentication mengambil username:password, Base64-encode seluruh string itu (memperlakukannya sebagai byte, tetapi karena itu ASCII ia berfungsi), dan meletakkannya di header Authorization. Ini bukan karena Base64 aman (bukan) - itu karena header perlu bertahan dari transmisi melalui sistem yang mungkin merusak teks mentah dengan titik dua dan karakter khusus. Keamanannya berasal dari HTTPS, bukan dari Base64.

Alur kerja praktis

Base64 tool kami menangani encoding dan decoding: tempel teks → dapat Base64 (untuk dipakai di JSON, data URI, dll.), tempel Base64 → dapat teks kembali (untuk membaca JWT, mendecode token), atau upload file → dapat Base64 (untuk mentransmisikan file sebagai teks).

Untuk URL encoding, setiap bahasa sudah punya fungsi bawaan:

• JavaScript: encodeURIComponent(str) / decodeURIComponent(str)
• Python: urllib.parse.quote(str) / urllib.parse.unquote(str)
• PHP: urlencode($str) / urldecode($str)
• Ruby: CGI.escape(str) / CGI.unescape(str)

Untuk skenario gabungan (data biner dalam URL), polanya jelas: Base64 dulu, lalu URL-encode hasilnya kalau perlu — atau gunakan varian Base64 URL-safe langsung.

---

Intinya sederhana. URL encoding untuk membuat teks aman di URL. Base64 untuk membuat byte aman di teks. Keduanya untuk ketika Anda perlu data biner masuk ke dalam URL. Begitu aturan ini masuk ke kepala, kebingungannya hilang sendiri. Dan Base64 tool ada kapan pun Anda butuh penerjemah byte-ke-teks, berjalan secara lokal sehingga token sensitif tetap di perangkat Anda.