URL Pembuat
Bangun URL secara interaktif dengan skema, host, jalur, parameter kueri, dan fragmen.
Cara kerja
- Pilih skema dan host: pilih protokol (http, https, ftp) dan masukkan domain target.
- Tambahkan jalur dan parameter kueri: ketik jalur, lalu tambahkan pasangan kunci-nilai yang diperlukan.
- Tambahkan fragmen (opsional): tambahkan jangkar atau hash yang menunjuk ke bagian halaman tertentu.
- Salin URL yang dirakit: URL yang dihasilkan diperbarui secara langsung. Salin untuk digunakan dalam kode, pemasaran, atau pengujian.
Mengapa menggunakan pembangun URL?
Merakit URL secara manual rentan kesalahan, garis miring yang hilang, spasi yang tidak terkode, atau parameter kueri yang hilang dapat merusak deep link, panggilan API, atau pengalihan. Pembangun URL ini memastikan setiap komponen ditempatkan dan dikodekan dengan benar, menghasilkan URL yang valid setiap saat. Sangat ideal untuk membuat tautan pemasaran terlacak, membangun endpoint API selama pengembangan, merakit deep link untuk kampanye email, dan mendokumentasikan struktur URL.
Fitur
- Beberapa skema: http, https, dan ftp didukung secara default.
- Encoding otomatis: spasi dan karakter khusus dalam nilai parameter dikodekan dengan benar untuk URL.
- Beberapa parameter kueri: tambahkan sebanyak pasangan kunci-nilai yang Anda perlukan.
- Salin ke clipboard: salin sekali klik dari URL lengkap yang dihasilkan.
- Pratinjau langsung: URL diperbarui saat Anda mengetik untuk melihat hasilnya segera.
Pertanyaan yang sering diajukan
Apa saja bagian-bagian URL?
URL lengkap mencakup: skema (https), host (example.com), port opsional (:8080), jalur (/api/v1), kueri (?kunci=nilai), dan fragmen (#bagian). Pembangun ini mencakup setiap komponen.
Apakah ia menangani karakter khusus?
Ya. Spasi, huruf beraksen, simbol, dan karakter non-ASCII lainnya dalam nilai parameter dikodekan secara otomatis sehingga URL yang dihasilkan valid di peramban atau klien API mana pun.
Apakah parameter URL memengaruhi SEO?
Parameter pelacakan (seperti tag UTM) umumnya tidak memengaruhi peringkat penelusuran organik. Untuk menghindari penalti konten duplikat ketika banyak URL bertanda hidup berdampingan, pastikan tag canonical Anda menunjuk ke versi bersih dari setiap halaman.
Anatomi sebuah URL, komponen demi komponen
Tata bahasa yang mendefinisikan setiap URL di web hidup di RFC 3986 «Uniform Resource Identifier (URI): Generic Syntax» (Berners-Lee, Fielding, Masinter, Januari 2005). Browser sebenarnya menggunakan varian yang sedikit lebih toleran yang didefinisikan dalam WHATWG URL Living Standard. Keduanya sepakat tentang komponen-komponennya:
- Skema,
https,http,ftp,mailto,data,tel,sms,magnet, ditambah skema aplikasi kustom (myapp://). RFC 3986 mensyaratkan huruf kecil; WHATWG mengkanonikalisasi. Registry Skema URI IANA memiliki daftar resmi skema yang terdaftar. - Otoritas,
userinfo@host:port. Bentuk kredensial tertanamuser:password@sudah usang karena alasan keamanan: Chrome 64 (Januari 2018) memblokir pemuatan sumber daya sekunder dengan kredensial di URL karena memungkinkan trik phishing. - Host, nama domain atau literal IP. Nama domain yang diinternasionalisasi seperti
президент.рфdikonversi ke ASCII via Punycode (RFC 3492, Maret 2003): contoh itu menjadixn--d1abbgf6aiiy.xn--p1ai. Browser melakukan konversi secara transparan untuk tampilan. - Port, hanya disertakan ketika tidak default untuk skema. Default: 80 (http), 443 (https), 21 (ftp), 22 (ssh), 25 (smtp), 5432 (postgres), 3306 (mysql), 6379 (redis).
- Jalur, segmen yang dipisahkan oleh garis miring. Setiap segmen mengenkode persen apa pun yang berada di luar set
pcharyang didefinisikan di RFC 3986 §3.3. Segmen titik.dan..memiliki semantik penghapusan (§5.2.4). - Kueri, secara konvensi pasangan kunci-nilai dipisahkan oleh
&, tetapi RFC 3986 hanya mengatakan «string buram setelah?». Konvensi diformalkan dalam algoritma WHATWGapplication/x-www-form-urlencoded. - Fragmen, semua setelah
#. Tidak pernah dikirim ke server. Digunakan oleh router aplikasi halaman tunggal, jangkar tautan, dan token aliran implisit OAuth.
Persen-encoding: jebakan + versus %20
RFC 3986 §2.3 mendefinisikan karakter tidak dicadangkan yang tidak pernah memerlukan enkode: A-Z a-z 0-9 - . _ ~. Yang lainnya, ketika muncul sebagai data di dalam komponen URL, menjadi %XX di mana XX adalah nilai heks byte. Karakter UTF-8 multi-byte berkembang menjadi beberapa triplet persen: é (U+00E9, UTF-8 C3 A9) mengenkode sebagai %C3%A9. Jebakan klasiknya adalah karakter spasi: dalam jalur atau fragmen URL biasa, spasi mengenkode sebagai %20; dalam string kueri yang dienkode form (algoritma application/x-www-form-urlencoded yang dibagikan oleh form HTML dan serializer string kueri WHATWG), spasi mengenkode sebagai +. Server yang mendekode data form mengkonversi + kembali ke spasi; server yang memperlakukan kueri sebagai URI generik tidak. Mencampur dua konvensi secara diam-diam merusak data. Pola aman di JavaScript: gunakan new URLSearchParams untuk kueri dan encodeURIComponent untuk nilai individu; kepatuhan spec diurus untuk Anda.
Di mana Anda benar-benar membutuhkan pembangun URL
- Tautan pemasaran yang ditandai UTM untuk Google Analytics (Urchin Tracking Module, di GA sejak 2005): lima parameter kanonis adalah
utm_source,utm_medium,utm_campaign,utm_content,utm_term, semua huruf kecil sesuai panduan Google sendiri. - Permintaan otorisasi OAuth 2.0 (RFC 6749, Oktober 2012): spec mewajibkan
response_type,client_id,redirect_uri,scope,statesebagai parameter kueri di endpoint otorisasi. - Deep link seluler: skema
app://yang OS rutekan ke aplikasi terinstal Anda alih-alih browser, atau Android App Link / iOS Universal Link yang dilayani dari domain Anda. - Pengujian klien API:
https://api.example.com/v2/users?expand=projects&since=2024-01-01. Mengetik ini secara manual secara konsisten gagal di langkah «spasi di dalam nilai». - Pembuster cache CDN:
?v=2026-05-12-1ditambahkan ke URL aset statis sehingga deploy membatalkan versi cache. String kueri adalah bagian dari kunci cache. - Layanan transformasi gambar (Cloudinary, imgix, Cloudflare Images): transformasi dienkode sebagai parameter kueri atau segmen jalur. Panggilan tipikal terlihat seperti
?w=800&q=85&fm=webp. - Template email di mana halaman tujuan membaca parameter via JS, sering menggabungkan tag UTM dengan
tokenatauuidunik untuk pelacakan per penerima.
Kesalahan umum
- Lupa mengenkode
&di dalam nilai. Nilai «kucing & anjing» dijatuhkan secara naif ke?spesies=kucing & anjingmenjadi kuncispesiesdengan nilaikucingditambah kunci kosong yang nyasar. Selalu lewatiencodeURIComponent. - Enkode ganda. Memanggil
encodeURIComponentpada string yang sudah dienkode mengubah%20menjadi%2520. Mudah ketika nilai melewati dua sistem yang masing-masing «mengenkode secara defensif». - Ketidakcocokan garis miring akhir. RFC 3986 mengatakan bahwa
https://example.com/apidanhttps://example.com/api/adalah sumber daya yang berbeda. Kebanyakan API REST memperlakukannya secara identik, tetapi beberapa mengembalikan pengalihan 308; pilih satu bentuk kanonis dan dokumentasikan. - Mencampur
+dan%20. String kueri yang dienkode form menggunakan+untuk spasi; pengenkodean persen generik menggunakan%20. Jalur dengan+literal bertahan dari salin-tempel tetapi gagal saat dekoder form membacanya. - Kredensial tertanam.
https://user:pass@example.comsudah usang dan diblokir untuk pemuatan sumber daya sekunder di Chrome 64+. Gunakan headerAuthorization. - Spoofing IDN. Sirilik «а» (U+0430) secara visual identik dengan Latin «a». Browser menampilkan Punycode ketika domain mencampur skrip, tetapi URL yang dikonstruksi secara manual mengarah ke
аpple.com(а sirilik) membuka situs yang berbeda dariapple.com. Gunakan Punycode (xn--...) untuk keamanan, atau tetap dengan ASCII. - Menambahkan
//setelah skema yang tidak menggunakannya.mailto:,tel:,sms:,magnet:semua melewatkan//dan langsung ke jalur.mailto:user@example.combenar;mailto://...tidak.
Pertanyaan yang lebih sering diajukan
Berapa panjang maksimum URL?
RFC 3986 tidak menetapkan batas. Dalam praktik: browser membatasi sekitar 2.000 karakter untuk bilah alamat (Internet Explorer 11 adalah 2.083; Chrome dan Firefox mentolerir lebih panjang tetapi memotong tampilan); kebanyakan CDN dan proxy membatasi pada 4.096 atau 8.192; server seperti Apache dan Nginx default ke 8.192 byte untuk baris permintaan. Jika Anda perlu lebih dari 2.000 karakter, beralihlah ke body POST.
Bisakah saya menyertakan parameter kueri yang sama beberapa kali?
Ya. ?tag=red&tag=blue&tag=green valid. Bagaimana server menginterpretasikannya tergantung pada framework: Express / Node.js mem-parse ke req.query.tag = ['red', 'blue', 'green']; PHP membutuhkan konvensi tanda kurung ?tag[]=red&tag[]=blue; Rails mem-parse ke array jika Anda menggunakan tanda kurung tag[]. Metode URLSearchParams.getAll('tag') selalu mengembalikan semua nilai sebagai array terlepas dari gaya tanda kurung.
Apakah parameter kueri memengaruhi SEO?
Parameter pelacakan (UTM, fbclid, gclid) umumnya tidak memengaruhi peringkat pencarian organik. Risikonya adalah pengindeksan konten duplikat: URL bertag dan versi bersihnya terlihat seperti dua halaman berbeda bagi crawler. Perbaikannya adalah tag <link rel="canonical" href="clean-url"> yang menunjukkan setiap varian bertag ke URL kanonis yang sama.
Apa itu Template URI, dan haruskah saya menggunakannya?
RFC 6570 (Maret 2012) mendefinisikan Template URI: sintaks untuk URL parameter dengan placeholder. Mereka digunakan dalam spesifikasi OpenAPI / Swagger, JSON Hyper-Schema, dan beberapa API HATEOAS. Untuk konstruksi URL sehari-hari, konkatenasi string biasa melalui builder ini lebih sederhana; Template URI bersinar saat mendokumentasikan permukaan API dan menghasilkan SDK klien.
Apakah ada yang dikirim ke server?
Tidak. Setiap komponen yang Anda ketik, pengkodean, dan URL akhir dibangun di JavaScript browser Anda. Tidak ada panggilan jaringan yang dibuat untuk merakit URL. Buka tab Jaringan di DevTools dan coba alat ini: Anda akan melihat nol permintaan keluar selama konstruksi.