What Happens to an Arabic Title When You Generate a URL Slug

Type مقال عن البرمجة (an article about programming) into the slug generator and the result is مقال-عن-البرمجة - the Arabic words kept whole, joined by a hyphen exactly where the spaces were. That's not the default behavior of most slug generators built with English titles in mind, and it's worth explaining plainly, because the alternative most tools reach for instead would either mislead you or quietly throw away what you typed.

The three options, and why two of them are worse than they look

A slug generator that hits non-Latin input has three real choices. The first is to guess at a Latin transliteration - turning Arabic letters into their approximate Latin sound-alikes. That sounds helpful and isn't: there's no single, agreed transliteration standard for Arabic suitable for a URL (several competing romanization schemes exist, none of them universally "correct"), and doing it without a real transliteration library means hand-rolled letter substitution that produces results indistinguishable from guessing. Worse, it actively misleads - it looks like the tool understood the title when it was really just pattern-matching letters.

The second option is to strip non-Latin characters entirely. This is the one that fails most quietly: an Arabic title collapses to an empty or near-empty slug, which looks like the tool succeeded (it returns something, or falls back to a numeric ID) while actually discarding the entire meaning of what was typed. A reader glancing at the URL gets no information about the page at all.

The third option - the one this tool uses - is to preserve the script, lowercase where the script has a concept of case, and strip only characters that are genuinely unsafe or unwanted in a slug. It needs no transliteration table, no library, and it never discards meaning the user actually typed.

A mixed-script title works exactly the way you'd expect

Type React مقدمة and the slug comes out as react-مقدمة - the Latin word and the Arabic word each kept intact, joined by a hyphen where the space was, reading left to right in the same order they were typed. Arabic letters still shape and join correctly within their own word; what's fixed in place is the left-to-right order of the hyphen-separated segments, because a URL path is a structural value read in byte order, not a line of prose.

This isn't an unusual thing for a URL to contain

A percent-encoded Unicode path segment is a valid, well-supported part of a URL in every modern browser and server - this isn't a workaround or an edge case being tolerated, it's ordinary, established behavior. WordPress has generated non-Latin post slugs this way by default for years. A URL ending in an Arabic phrase works exactly as well, technically, as one ending in an English phrase; the difference is entirely about who can read it at a glance, not whether it functions.

Numbers and diacritics inside a non-Latin title

Numbers pass through unchanged in whatever numeral system was actually typed. Arabic diacritics (the tashkeel marks used for vowelization in formal or religious text) are stripped the same way Latin accents are, using a separate rule specific to how those marks are encoded - they're not decomposed the same way an accented Latin letter is, so they need their own handling rather than being covered by the same normalization step. The same underlying idea covers French, German and Spanish titles too: accented letters are simplified to their base form (é to e, ü to u, ñ to n), which is the ordinary, expected behavior any slug generator built for those languages should have - the difference with Arabic is only that there's no equivalent "base form" to simplify to, since the letters themselves aren't variations of a Latin base letter, so preservation is the only option that doesn't discard something.

Who this actually matters for

A blog or documentation site publishing in Arabic, or any CMS collecting titles from users who don't type in English, hits this immediately and constantly, not as an edge case. A slug generator that quietly mangles or empties every non-Latin title forces a workaround - typing an English placeholder title just to get a usable URL, then editing the real title in afterward - which is exactly the kind of friction a tool like this should remove, not add.

Why this is worth stating plainly rather than leaving to be discovered

Nothing about a slug generator's page usually says what happens to a non-English title - it's simply tried, and the result either works or doesn't. For a title in Arabic, French, German or Spanish, that silence is where an unhappy surprise usually lives: a title typed in good faith, and a slug that comes back empty, or full of question marks, or replaced by a number, with no explanation of why. Saying the actual behavior up front - preserved, not guessed at, not dropped - is worth more than pretending it never comes up.

Try it directly: paste a non-English title into the slug generator and read the result, or work through the how-to guide for the full set of options either way.