URL Encoding Dijelaskan: Percent-Encoding dalam HTTP Request

URL terlihat sederhana dari luar — serangkaian teks yang menunjuk ke suatu resource. Namun di baliknya, URL mengikuti tata bahasa ketat yang hanya mengizinkan sekumpulan karakter tertentu. Begitu kamu mencoba memasukkan spasi, ampersand, atau karakter non-ASCII dalam URL tanpa mengkodenya, semuanya akan rusak dengan cara yang sulit di-debug. Percent-encoding (yang umum disebut URL encoding) adalah mekanisme yang membuat data arbitrer aman untuk disematkan dalam URL.

Kamu bisa mengkode dan mendekode URL secara instan dengan BrowseryTools URL Encoder/Decoder — gratis, tanpa daftar, semuanya tetap di browser.

Mengapa Karakter Khusus Merusak URL

Spesifikasi URL (RFC 3986) mereservasi karakter-karakter tertentu untuk tujuan struktural. Tanda ? memisahkan path dari query string. Tanda & memisahkan parameter query satu sama lain. Tanda # menandai fragment identifier. Tanda /memisahkan segmen path. Jika datamu mengandung karakter-karakter ini, parser URL tidak dapat membedakan antara datamu dan struktur URL itu sendiri.

Pertimbangkan query penelusuran untuk rock & roll. Konstruksi URL secara naif menghasilkan:

/search?q=rock & roll
          ^     ^
          |     └── looks like a new parameter begins here
          └── this & splits q from a phantom second parameter

Parser membaca q=rock (dengan spasi di belakang) sebagai parameter pertama, lalu menemukan apa yang terlihat seperti awal parameter kedua bernama roll. Kedua nilai tersebut salah. URL yang benar adalah /search?q=rock%20%26%20roll — spasi menjadi %20 dan ampersand menjadi %26.

Apa yang Sebenarnya Dilakukan Percent-Encoding

Percent-encoding mengkonversi satu byte menjadi urutan tiga karakter: tanda persen literal diikuti oleh dua digit heksadesimal huruf besar yang merepresentasikan nilai byte tersebut. Karakter spasi (byte ASCII 32, hex 0x20) menjadi %20. Tanda at (@, ASCII 64, hex 0x40) menjadi %40. Aturannya adalah:

percent-encode(byte) = "%" + byte.toString(16).toUpperCase().padStart(2, "0")

Examples:
  space  (0x20) → %20
  @      (0x40) → %40
  [      (0x5B) → %5B
  €      (UTF-8: 0xE2 0x82 0xAC) → %E2%82%AC

Untuk karakter Unicode multi-byte (apa pun di luar ASCII), karakter tersebut pertama-tama dikodekan ke byte UTF-8, lalu setiap byte di-percent-encode. Simbol euro €adalah tiga byte UTF-8, sehingga menjadi tiga urutan percent-encoded: %E2%82%AC.

Karakter Aman vs Karakter Tereservasi

Tidak setiap karakter perlu dikodekan. RFC 3986 mendefinisikan dua set yang aman digunakan apa adanya:

• Karakter unreserved — A–Z, a–z, 0–9, tanda hubung, garis bawah, titik, tilde. Ini tidak memiliki arti khusus dan tidak pernah perlu dikodekan.
• Karakter reserved — : / ? # [ ] @ ! $ & ' ( ) * + , ; =. Ini AMAN di posisi strukturalnya, tetapi harus dikodekan ketika muncul sebagai nilai data.

Semua karakter lainnya — spasi, Unicode, karakter kontrol, sebagian besar tanda baca — harus selalu dikodekan.

encodeURI vs encodeURIComponent: Perbedaan yang Krusial

JavaScript memiliki dua fungsi enkoding bawaan, dan mengacaukannya adalah salah satu bug URL-encoding yang paling umum di aplikasi web.

encodeURI() dirancang untuk mengkodekan URL lengkap. Ia membiarkan semua karakter reserved tetap karena secara struktural bermakna dalam URL penuh. Kamu akan menggunakannya jika memiliki URL lengkap yang mungkin mengandung spasi atau Unicode tetapi memiliki struktur yang valid:

encodeURI("https://example.com/search?q=hello world&lang=en")
// → "https://example.com/search?q=hello%20world&lang=en"
//   ✓ space encoded, but & and ? left intact

encodeURIComponent() dirancang untuk mengkodekan satu nilai — nilai parameter query, segmen path, apa pun yang perlu diperlakukan sebagai data murni. Ia juga mengkodekan karakter reserved, termasuk &, =, ?, dan /:

encodeURIComponent("rock & roll")
// → "rock%20%26%20roll"
//   ✓ & encoded — safe to use as a query parameter value

encodeURIComponent("https://example.com/page")
// → "https%3A%2F%2Fexample.com%2Fpage"
//   ✓ colons and slashes encoded — safe as a redirect_uri value

Aturan praktisnya: saat membangun URL, gunakan encodeURIComponent() pada setiap nilai parameter individu, jangan pernah pada URL lengkap. Gunakan encodeURI()hanya pada URL lengkap yang ingin kamu normalisasi. Dalam kode modern, lebih baik gunakan API URL dan URLSearchParams daripada enkoding manual — keduanya menangani enkoding secara otomatis dan benar.

Jebakan Enkoding Query String

Beberapa bug halus muncul berulang kali saat mengkodekan query string. Tanda +layak disebut secara khusus: dalam format application/x-www-form-urlencoded (format yang digunakan form HTML saat submit), spasi dikodekan sebagai + bukan %20. Ini adalah konvensi lama yang mendahului RFC 3986. Jika backend URL-decoding menggunakan aturan form-encoding dan frontend mengirim %20, itu berfungsi. Tetapi jika frontend mengirim + dan backend mendekode dengan aturan RFC 3986, + dibiarkan sebagai tanda plus literal — bukan spasi.

// URLSearchParams uses application/x-www-form-urlencoded (+ for spaces)
new URLSearchParams({ q: "rock & roll" }).toString()
// → "q=rock+%26+roll"

// encodeURIComponent uses RFC 3986 (%20 for spaces)
"q=" + encodeURIComponent("rock & roll")
// → "q=rock%20%26%20roll"

// Both are valid — just be consistent on both ends

Cara Data Form Di-URL-Encode

Ketika form HTML submit dengan method="GET", browser menserialisasi field form menjadi query string menggunakan application/x-www-form-urlencoded. Setiap nama dan nilai field dikodekan (spasi sebagai +, karakter khusus sebagai %XX), dan field digabungkan dengan &. Untuk form method="POST" tanpa atribut enctype, enkoding yang sama digunakan tetapi data masuk ke body request, bukan URL.

Ini juga format yang digunakan fetch() saat kamu memasukkan objek URLSearchParams sebagai body, dan itulah yang paling banyak framework server-side dekode secara otomatis saat membaca form submission.

Base64 dalam URL

Base64 standar menggunakan + dan / — keduanya memiliki makna khusus dalam URL. Ketika data yang dikodekan Base64 perlu muncul dalam URL (pola umum untuk token, data gambar, atau tanda tangan kriptografis), gunakan varian Base64URL sebagai gantinya. Ia menggantikan + dengan - dan / dengan _, menghasilkan string yang aman di posisi URL mana pun tanpa enkoding lebih lanjut. JWT menggunakan format ini untuk segmen header dan payload mereka.

Bug Enkoding di Dunia Nyata

Beberapa pola bug yang muncul di aplikasi production:

• Double-encoding — mengkodekan URL yang sudah dikodekan. %20 menjadi %2520 karena % itu sendiri dikodekan menjadi %25. Selalu periksa apakah nilai sudah dikodekan sebelum mengkodekannya lagi.
• Lupa encodeURIComponent pada redirect_uri — alur OAuth memasukkan redirect_uri sebagai parameter query. Jika mengandung ? atau & dan tidak dikodekan, server auth akan memparsing karakter tersebut sebagai bagian dari struktur URL luar, merusak redirect.
• Enkoding non-UTF-8 — sistem lama atau server yang salah konfigurasi terkadang melakukan percent-encode string menggunakan ISO-8859-1 alih-alih UTF-8. Urutan byte untuk é berbeda di antara keduanya. Selalu terapkan UTF-8 secara konsisten di kedua sisi.
• Mencatat URL mentah — mencatat URL yang mengandung data pengguna yang dikodekan dapat menghasilkan log yang menyesatkan jika log viewer mendekode urutan percent secara otomatis, menyembunyikan apa yang sebenarnya dikirim.

Enkode dan Dekode URL Secara Instan

Apakah kamu sedang men-debug redirect OAuth, membangun query string secara manual, memeriksa request API yang salah format, atau hanya ingin memahami apa yang sebenarnya ada di dalam URL yang di-percent-encode — BrowseryTools URL Encoder/Decoder menanganinya secara instan. Tempel stringmu, pilih enkode atau dekode, dan lihat hasilnya langsung. Tanpa panggilan server, tanpa daftar.