Pembuat URL Slug

Ubah teks apa pun menjadi slug yang ramah URL.

Hanya-browser: teks Anda tidak pernah meninggalkan perangkat Anda


Apa itu slug URL?

A slug is the human-readable, URL-safe path segment that identifies a page within a site. It sits at the tail of the URL and replaces what would otherwise be an opaque database identifier with a descriptive token. In https://example.com/blog/2026/my-awesome-post, the slug is my-awesome-post. Mechanically, a slug is the output of a deterministic transformation: take an arbitrary input string, strip everything that isn't allowed in a URL path segment, fold case, replace whitespace with a separator, and emit ASCII. The transformation is one-way in practice, you can't reliably reconstruct "My Awesome Post: Take Two!" from my-awesome-post-take-two: which is why slugs are stored alongside the original title, not in place of it.

Slug yang baik hanya menggunakan huruf kecil, angka, dan tanda hubung. Mereka menghapus aksen, karakter khusus, dan spasi berlebih. Ini meningkatkan SEO dan pengalaman pengguna · mesin pencari dan manusia dapat membaca URL dan memahami konten halaman.

Dari Mana Kata Itu Berasal: Newsroom Abad ke-19

Kata itu mendahului web satu abad. Di ruang penyusunan era-Linotype, setiap baris jenis dilemparkan sebagai satu strip logam: "slug": sekitar tiga puluh picas lebar dan beratnya sekitar dua belas ons timah. Istilah itu kemudian beralih makna menjadi pengidentifikasi pendek yang ditulis editor di bagian atas cerita untuk melabelinya melalui produksi: pegangan satu- atau dua-kata seperti walikota-anggaran atau sekolah-kebakaran yang dapat digunakan jurnalis, sub-editor, dan tipografer untuk merujuk pada cerita tanpa mengetik judul lengkap. Panduan gaya AP dan harian besar masih mendokumentasikan penggunaannya.

Ketika Movable Type, WordPress, dan dokumen Django awal mengadopsi "slug" sebagai nama field di awal 2000-an, mereka meminjam istilah newsroom secara grosir. Dokumentasi Django telah menyebut field tersebut slug setidaknya sejak rilis 0.91 pada 2005, dengan definisi yang sekarang kanonis: label pendek yang hanya berisi huruf, angka, underscore, atau hyphen, umumnya digunakan dalam URL. Metafora mendarat dengan tepat karena baik slug timah-cor maupun slug URL adalah token pendek, berbeda, ramah-mesin yang menunjuk ke hal yang lebih panjang.

RFC 3986 dan Set Karakter Tidak-Dicadangkan

URL syntax is defined by RFC 3986 ("Uniform Resource Identifier (URI): Generic Syntax"), published January 2005 by Tim Berners-Lee, Roy Fielding and Larry Masinter, replacing RFCs 2396 and 2732. It is an STD 66 Internet Standard, the IETF's highest maturity tier, reserved for protocols of demonstrated stability and broad implementation. Section 2.3 of RFC 3986 defines the unreserved characters, the only characters that are guaranteed to be safe in any URI component without percent-encoding: A-Z, a-z, 0-9, hyphen, period, underscore, and tilde. That's sixty-six characters total. Everything else is either a reserved character (with structural meaning in some URI component) or "other", anything in the latter group must be percent-encoded if it appears in a URI.

Karena set tidak-dicadangkan adalah satu-satunya set yang dijamin untuk round-trip dengan bersih melalui setiap parser URI yang pernah ditulis, generator slug konvergen pada pipeline yang hampir identik: ubah karakter alfabet ke huruf kecil, simpan digit, simpan hyphen, ganti spasi dengan satu hyphen, dan baik strip-or-transliterasi semua yang lain. Underscore, titik, dan tilde secara teknis diizinkan tetapi konvensional dihindari dalam slug: titik bentrok dengan ekstensi file, tilde dibaca sebagai direktori home dalam konvensi URL lama, dan underscore kalah dari hyphen untuk alasan SEO yang tercakup di bawah.

"Cool URIs Don't Change": Berners-Lee, 1998

Catatan gaya Tim Berners-Lee 1998 "Cool URIs Don't Change", dihosting di situs W3C, adalah karya filosofi slug yang paling banyak dikutip yang pernah ditulis. Baris pembukanya terkenal: URI cool adalah yang tidak berubah. Catatan kemudian dibaca sebagai polemik terhadap desain URL yang memanggang detail implementasi sementara ke dalam path. Yang direkomendasikan tidak dilakukan telah membentuk praktik slug selama hampir tiga puluh tahun: jangan letakkan ekstensi alat-authoring ke dalam URL: mereka membocorkan implementasi dan rusak ketika Anda bermigrasi; jangan letakkan status ke dalam URL: halaman keluar dari "saat ini" tetapi URL seharusnya tidak; jangan letakkan nama penulis: penulis pindah; jangan letakkan tanggal kecuali tanggal mendasar bagi sumber daya; jangan letakkan ID sesi, parameter query, atau status login ke dalam URL kanonis.

Slug: kata-kata yang deskriptif, semantik, hyphen-huruf-kecil: persis apa yang diizinkan dalam URI "cool". Yang lain adalah dekorasi struktural yang seharusnya tidak meleleh ke dalam alamat. Desain permalink WordPress, SlugField Django, dan to_param Rails semua menginternalisasi panduan ini: pancarkan URL yang merupakan makna halaman, bukan mekanisme bagaimana itu disajikan.

Hyphen Mengalahkan Underscore: dan Itu Didokumentasikan

Dalam wawancara WebmasterWorld 2005, insinyur Google Matt Cutts mengatakan hyphen diperlakukan sebagai pemisah kata oleh tokenizer Google, sementara underscore adalah penggabung kata. Jadi green-apples dibaca sebagai dua token green dan apples, sementara green_apples dibaca sebagai token tunggal green_apples. Untuk kueri "green apples", URL yang di-hyphen akan cocok dengan pemeriksaan title-keyword; URL yang di-underscore tidak. Cutts meninjau kembali ini pada 2007 di blognya dan dalam video Google Webmaster Help 2011 di YouTube ("Underscores vs. dashes in URLs"), menegaskan kembali nasihat yang sama dan mencatat bahwa Google pada satu titik telah mengevaluasi mengubah perilaku underscore untuk juga bertindak sebagai pemisah tetapi tidak melakukannya karena akan merusak terlalu banyak URL yang ada yang sengaja menggunakan underscore sebagai penggabung (__init__.py, nama fungsi pemrograman).

Halaman "URL structure best practices for Google Search" Google saat ini merekomendasikan hyphen secara langsung: URL seperti /green-dress.html lebih berguna daripada /greendress.html, dan Anda harus menggunakan hyphen alih-alih underscore. Rekomendasi telah didokumentasikan secara terus-menerus selama lebih dari dua puluh tahun. Efeknya kecil per URL tetapi terkumpul di seluruh situs ribuan halaman, dan mengonversi hyphen ke underscore tidak memiliki keuntungan: tidak ada skenario SEO di mana underscore menang. Setiap panduan slug yang dapat dipercaya berakhir dengan saran yang sama: gunakan hyphen.

Normalisasi Unicode: Bagaimana NFD Melucuti Aksen

Standar Unicode mendefinisikan dua cara untuk meng-encode banyak karakter beraksen: precomposed (satu code point, di mana é adalah U+00E9) dan decomposed (huruf dasar diikuti oleh tanda combining, di mana é adalah U+0065 plus U+0301, aksen acute combining). Visual identik, byte-untuk-byte berbeda. Unicode Technical Standard #15 mendefinisikan empat bentuk normalisasi: NFC, NFD, NFKC, NFKD: dan untuk generasi slug, NFD adalah leveragenya. Jika Anda mengambil string input, menormalkan ke NFD, lalu melucuti setiap code point dalam rentang Unicode U+0300 hingga U+036F (blok Combining Diacritical Marks), Anda mendapatkan kembali huruf ASCII dasar. Café menjadi cafe, naïve menjadi naive, François menjadi Francois, niño menjadi nino, crème brûlée menjadi creme brulee.

NFD tidak melipat karakter yang tidak dapat didekomposisi menjadi base+mark. ß Jerman (s tajam) tidak terurai menjadi ss di bawah NFD: itu memerlukan transliterasi eksplisit. ł Polandia (l dengan stroke) tidak terurai menjadi l. ø Norwegia tidak terurai menjadi o. þ Islandia (thorn) dan ð (eth) memerlukan tabel pencarian. Browser telah secara native mendukung String.prototype.normalize() sejak sekitar 2015 (Chrome 34, Firefox 31, Safari 10), itulah mengapa bahkan utility slugify JavaScript kecil dapat melakukan pekerjaan pelucutan-diakritik tanpa pustaka.

Keluarga Pustaka Slugify: Apa yang Dikirim Setiap Ekosistem

django.utils.text.slugify() Django telah ada di framework Python sejak awal 2000-an. Itu mengubah ke huruf kecil, melucuti karakter yang tidak ada di [A-Za-z0-9_-], dan menggantikan spasi dengan hyphen. Sejak Django 1.9 (2015) keyword allow_unicode=True beralih ke mode Unicode-aware yang mempertahankan huruf non-ASCII. Itu adalah implementasi referensi yang disalin oleh semua orang. Di Node.js, @sindresorhus/slugify Sindre Sorhus adalah paket slugify yang paling banyak diunduh di npm, dengan jutaan unduhan mingguan: fitur termasuk pemisah yang dapat dibaca manusia, penggantian yang dapat disesuaikan (sehingga Anda dapat memetakan & ke and, @ ke at), penanganan Unicode dan huruf-kecil sadar-locale (I bertitik/tidak-bertitik Turki, Jerman ß → ss). Untuk pengguna Python yang tidak menggunakan Django, python-slugify Val Neekman di PyPI membungkus pustaka transliterasi unidecode dan menambahkan perilaku khusus-slug: word-splitting regex, karakter penggantian, panjang maksimum, penghapusan stop-word.

Ekosistem lain mengikuti pola yang sama. PHP memiliki cocur/slugify Cocur di Packagist, digunakan oleh plugin Laravel dan Symfony, dan Symfony sendiri mengirim AsciiSlugger di symfony/string sejak versi 5.0. Ruby on Rails menggunakan String#parameterize, dibangun ke dalam ActiveSupport setidaknya sejak Rails 1.0; gem friendly_id melapisi pelacakan-riwayat dan penanganan-tabrakan di atas. Go memiliki gosimple/slug dengan tabel locale untuk lebih dari delapan puluh bahasa. Rust memiliki crate slug. Java memiliki Apache Commons Text dan slugify-jvm. Hal yang luar biasa adalah seberapa konvergen API: input string masuk, slug string keluar, dengan segenggam opsi yang sama: pemisah, panjang-maks, huruf-kecil, locale. Alat Absolutool berada di keluarga yang sama tetapi berjalan sepenuhnya di browser Anda, tanpa pustaka untuk diinstal.

WordPress: 43% Web Menjalankan Pipeline Ini

WordPress adalah sistem pemancar-slug tunggal terbesar di web: itu menggerakkan sekitar 43% dari semua situs web menurut survei W3Techs 2026, sehingga konvensi slug-nya secara efektif adalah konvensi slug web untuk sebagian besar pembaca. Ketika pos disimpan, WordPress secara otomatis menghasilkan slug dari judul melalui sanitize_title() (yang memanggil sanitize_title_with_dashes() untuk kasus rewrite default): huruf kecil, lucuti HTML, decode entitas, ganti spasi dan sebagian besar tanda baca dengan hyphen, percent-encode karakter yang tidak aman, kompresi hyphen yang berdekatan, pangkas hyphen awal/akhir. Jika hasilnya bertabrakan dengan slug pos yang ada, WordPress menambahkan -2, -3, dan seterusnya. Slug dapat diedit di editor pos: setelah pos diterbitkan, mengubah slug merusak setiap tautan yang ada kecuali penerbit mengatur redirect. WordPress secara historis tidak mentransliterasi karakter non-ASCII secara default; itu percent-encode mereka, yang menghasilkan URL Cyrillic yang terkenal jelek seperti %D0%BF%D1%80%D0%B8... yang plugin seperti Cyr-To-Lat ditulis untuk memperbaiki.

Di Luar Latin: Transliterasi untuk Cyrillic, CJK, Arab

NFD hanya menangani karakter yang terurai menjadi base ASCII + tanda combining. Untuk skrip non-Latin, pipeline slug membutuhkan transliterasi: pemetaan dari setiap karakter non-Latin ke ekuivalen skrip-Latinnya. Pustaka Python kanonis adalah unidecode, awalnya port dari Perl Text::Unidecode Sean M. Burke dari 2001, yang memetakan hampir setiap karakter di Basic Multilingual Plane ke string ASCII tebakan-terbaik: Москва → Moskva, Αθήνα → Athena. Fallback CJK adalah bagian yang kontroversial: unidecode menggunakan pinyin Mandarin untuk semua karakter CJK karena Cina memiliki cakupan karakter CJK terbesar, yang menghasilkan romanisasi yang tidak masuk akal untuk Jepang (東京 → Dong Jing dalam pinyin, bukan Tokyo). Alat khusus-Jepang seperti pykakasi melakukan pekerjaan mengonversi kanji + kana menjadi rōmaji yang tepat. Pustaka International Components for Unicode (ICU), dipelihara oleh Unicode Consortium dan IBM, menyediakan API Transliterator dengan set aturan bernama seperti Russian-Latin/BGN, Greek-Latin/UNGEGN, dan Han-Latin yang mengimplementasikan standar romanisasi resmi. Alat Absolutool berada di ujung yang lebih ringan: itu melipat diakritik Latin melalui NFD dan menjatuhkan semua yang lain. Pengguna yang ingin judul Rusia atau Cina yang di-slug dapat menjalankan langkah transliterasi terpisah sebelum menempel teks.

Batas Panjang URL: Dari Mana Aturan 2.000-Karakter Berasal

Tidak ada batas panjang yang ditentukan oleh RFC 3986 sendiri: sintaks URI tidak terbatas. Setiap batas adalah praktis. Internet Explorer secara historis membatasi URL pada 2.083 karakter (batas keras yang dipanggang ke dalam mesin Trident), yang merupakan asal dari aturan empiris "2.000 karakter" yang banyak dikutip. Chrome, Firefox, Safari, dan Edge modern mendukung URL hingga sekitar 64.000 hingga 100.000+ karakter di address bar. LimitRequestLine Apache default ke 8.190 byte untuk seluruh baris permintaan; large_client_header_buffers nginx default 8 KB; IIS default 16.384 byte untuk URL dan 4.096 untuk query string. RFC 9110 (HTTP/1.1, 2022) merekomendasikan dalam §4.1 bahwa server "seharusnya mampu menangani URI dengan panjang 8.000 oktet atau lebih panjang" tetapi berhenti pendek dari mewajibkan batas atas. Untuk slug, yang penting adalah bahwa mereka konvensional pendek: tiga hingga tujuh kata, tiga puluh hingga enam puluh karakter: untuk SEO dan kemudahan-berbagi. John Mueller Google telah mengatakan dalam beberapa Webmaster Hangouts bahwa panjang URL sendiri bukan sinyal peringkat, tetapi URL panjang dapat dipotong dalam snippet hasil pencarian, merugikan tingkat klik-tayang, dan terlihat tidak profesional dalam berbagi sosial. Sebagian besar generator slug mengekspos opsi panjang-maks untuk alasan ini; yang ini default ke tidak terbatas dan membiarkan Anda mengatur cap.

Penghapusan Stop-Word: Padat vs Gramatikal

Banyak pustaka slugify menawarkan penghapusan stop-word opsional: jatuhkan kata-kata pendek umum (a, an, the, of, is, and, or, to, in, for, on) sebelum merakit slug. Rasionalnya adalah mereka tidak menambahkan sinyal SEO dan padding URL. Jadi "The Best Way to Make a Cup of Tea" menjadi best-way-make-cup-tea (5 token, 24 karakter) alih-alih the-best-way-to-make-a-cup-of-tea (10 token, 35 karakter). Trade-off: lebih pendek dan padat, tetapi dengan keruntuhan tata bahasa sesekali (how-to-be-good dilucuti ke how-good kehilangan makna) dan risiko menghapus kata-kata yang sebenarnya membawa niat (art-of-war dilucuti ke art-war). WordPress tidak melucuti stop-word secara default: itu adalah perilaku plugin opt-in: dan sebagian besar generator slug modern membiarkannya nonaktif secara default dan memunculkannya sebagai checkbox. Yoast SEO untuk WordPress menandai slug yang berisi stop-word sebagai rekomendasi kecil daripada kesalahan. Generator ini tidak melucuti stop-word secara otomatis, dengan alasan bahwa penerbit mengetahui niat judul lebih baik daripada daftar kata statis. Jika Anda ingin mereka pergi, edit output secara langsung.

Tabrakan Slug: Apa yang Dilakukan CMS Ketika Dua Pos Memiliki Judul yang Sama

Ketika dua pos secara otomatis menghasilkan slug yang sama: "My Post" dan "My-Post!" keduanya menghasilkan my-post: sistem harus menyelesaikan konflik. Strategi paling umum: suffix numerik (my-post-2, my-post-3): dapat diprediksi, tidak pernah bertabrakan, tetapi suffix tidak membawa perbedaan semantik; prefiks tanggal (2026-04-27/my-post): bekerja dengan baik untuk konten blog dan merupakan default di Jekyll, Hugo, dan sebagian besar situs berita; suffix penulis (my-post-jane): digunakan oleh Medium dan blog multi-penulis; suffix hash acak (my-post-a3f9): digunakan oleh Stack Overflow, Notion, dan sistem shortlinking, menukar keterbacaan manusia untuk keunikan yang dijamin; atau edit manual pada waktu publikasi: secara editorial bersih tetapi jarang menjadi default karena itu mengganggu alur. Pilihan pragmatis untuk sebagian besar CMS adalah suffix numerik dengan pengeditan manual sebagai jalan keluar. Permalink yang diprefiks-tanggal populer untuk konten yang diankor-waktu di mana tanggal adalah informasi yang berarti.

Dampak SEO: Slug sebagai Sinyal Kecil tetapi Terlihat

Dokumentasi peringkat Google mencantumkan struktur URL sebagai sinyal peringkat kecil: konten halaman, backlink, sinyal engagement-pengguna, dan kebaruan semua membawa lebih banyak bobot. Tetapi kata-kata URL berkontribusi, dan mereka berkontribusi secara terlihat. Istilah slug muncul di baris URL snippet SERP di bawah judul, yang mempengaruhi tingkat klik-tayang bahkan ketika slug itu sendiri tidak diberi peringkat. Istilah slug dapat muncul di-bold di SERP jika cocok dengan kueri pengguna: bobot visual ekstra. Teks anchor dari tautan internal dan eksternal sering default ke URL ketika tidak ada teks tautan yang disediakan, sehingga slug semantik menjadi teks tautan dan membawa kata kunci-nya melalui ekuitas tautan masuk. Tes A/B di seluruh penerbit secara konsisten menunjukkan bahwa slug deskriptif meningkatkan CTR dengan persentase satu-digit dibandingkan ID opaque. Studi faktor-peringkat Backlinko 2020 (1,18 juta SERP yang dianalisis) menemukan URL pendek sedikit mengungguli URL panjang di bagian atas SERP.

Ada satu pengecualian untuk intuisi "lebih banyak kata kunci = lebih baik": keyword stuffing. Pembaruan Exact-Match Domain (EMD) September 2012 secara khusus mengurangi kredit untuk domain dan slug exact-match berkualitas rendah (cheap-life-insurance.com/buy-cheap-life-insurance), dan Google telah terus mendiskon keyword stuffing dalam URL sejak. Takeaway 2026: kehadiran kata kunci dalam slug membantu sederhana; keyword stuffing menyakiti. Kemenangan SEO terbesar tunggal dari slug adalah tidak mengubahnya setelah publikasi. Tautan masuk terkumpul ke URL. Otoritas halaman terkumpul di tingkat URL. Redirect 301 mempertahankan sebagian besar tetapi tidak semua ekuitas tautan, dan hanya jika penerbit benar-benar mengatur redirect: banyak yang tidak. Saran Berners-Lee "Cool URIs Don't Change" memiliki konsekuensi SEO langsung: setiap perubahan slug, bahkan dengan redirect, menelan biaya sejumlah kecil otoritas yang membutuhkan waktu untuk pulih.

Praktik SEO terbaik untuk slug

Pertanyaan umum

Apakah mendukung karakter beraksen?

Ya. Generator menggunakan normalisasi Unicode (NFD) untuk menghapus aksen. Misalnya, "cafe" tetap "cafe" sementara "café" juga menjadi "cafe". Ini menjamin slug yang bersih, dalam ASCII murni.

Haruskah menggunakan tanda hubung atau garis bawah?

Tanda hubung direkomendasikan untuk SEO. Dokumentasi resmi Google mengonfirmasi bahwa tanda hubung dalam URL diperlakukan sebagai pemisah kata, sedangkan garis bawah tidak. Jadi "artikel-saya" dibaca sebagai dua kata, sementara "artikel_saya" hanya membentuk satu.

Apa yang terjadi pada emoji dan simbol?

Emoji tidak ada dalam set karakter tidak-dicadangkan URL, dan NFD tidak mendekomposisinya: mereka tidak memiliki ekuivalen Latin. Generator ini menjatuhkan mereka. Alat lain percent-encode emoji (mengubah satu karakter menjadi string panjang seperti %F0%9F%94%A5), yang secara teknis berfungsi di browser modern tetapi menghasilkan URL yang tidak dapat dibaca dalam analytics, berbagi sosial, dan pratinjau email. Sebagian besar panduan slug merekomendasikan melucuti emoji sepenuhnya; jika Anda ingin mereka dipertahankan, percent-encode mereka di hulu langkah slug.

Apakah ini akan men-slug judul Rusia, Cina, atau Arab?

Tidak sendiri. NFD hanya melipat karakter beraksen skrip-Latin; itu tidak dapat mentransliterasi skrip Cyrillic, Yunani, Arab, Ibrani, atau CJK ke Latin. Menempel judul Rusia atau Cina ke alat ini akan menjatuhkan karakter-karakter tersebut dan menghasilkan slug yang kosong atau hampir kosong. Alur kerja yang tepat adalah menjalankan langkah transliterasi terlebih dahulu: unidecode Python, paket npm transliteration JavaScript, atau konvensi romanisasi Wikipedia: dan menempel hasil yang diromanisasi di sini. Untuk Jepang khususnya, gunakan alat kana-aware seperti pykakasi: transliterator CJK generik menerapkan pinyin Mandarin dan menghasilkan Dong Jing untuk 東京 alih-alih Tokyo.

Bagaimana jika saya perlu mengubah slug setelah publikasi?

Atur redirect 301 dari URL lama ke yang baru sebelum mengubah slug. 301 ("Moved Permanently") mempertahankan sebagian besar ekuitas tautan yang telah terkumpul ke URL lama dan memberi tahu crawler dan browser untuk memperbarui bookmark mereka. Tanpa redirect, setiap tautan masuk yang ada rusak dan Anda kehilangan otoritas halaman yang diwakili tautan tersebut. Bahkan dengan redirect, Anda kehilangan sejumlah kecil ekuitas yang membutuhkan minggu atau bulan untuk pulih. Maxim Berners-Lee: URI cool tidak berubah: sebagian estetis, sebagian kebenaran SEO: setiap perubahan slug menelan biaya sesuatu, sehingga layak mendapatkan slug yang tepat pertama kali.

Apakah ada panjang slug yang direkomendasikan?

Konvensi adalah tiga hingga tujuh kata, kira-kira tiga puluh hingga enam puluh karakter. Cukup panjang untuk menjadi deskriptif, cukup pendek sehingga snippet SERP Google tidak memotongnya dan manusia dapat memahami topik sekilas. Tidak ada maksimum teknis keras: RFC 3986 tidak menentukan satu dan browser modern menangani URL dalam puluhan ribu karakter: tetapi Apache, nginx, dan IIS memberlakukan cap praktis dalam rentang kilobyte, dan aturan legacy "2.000 karakter" dari Internet Explorer masih dikutip sebagai plafon cross-platform yang aman. Opsi Max Length di sini memungkinkan Anda men-cap output; mengaturnya ke 0 berarti tidak terbatas.

Apakah teks saya disimpan atau dikirim ke mana pun?

Tidak. Transformasi berjalan sepenuhnya di browser Anda menggunakan metode String.prototype.normalize() built-in JavaScript (didukung sejak Chrome 34, Firefox 31, Safari 10: kira-kira 2015). Tidak ada yang diunggah, tidak ada API yang dipanggil, tidak ada log yang ditulis. Anda dapat memverifikasi ini dengan membuka tab Network DevTools browser Anda saat Anda menghasilkan slug: tidak ada permintaan keluar. Halaman aman untuk slug yang berasal dari judul yang belum diterbitkan, dokumentasi internal, pos draf, atau konten lain yang tidak ingin Anda tinggalkan perangkat Anda.

Alat terkait

Encoder / decoder URL

Enkode atau dekode URL dan komponen URI.

Pengubah kapitalisasi

Konversi teks antara berbagai kapitalisasi.

Penghitung kata

Hitung kata, karakter, dan waktu baca.