Générateur de slug URL, gratuit

Transformez n'importe quel texte en slug compatible URL.

Tout-navigateur, votre texte ne quitte jamais votre appareil


Qu'est-ce qu'un slug d'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.

Les bons slugs n'utilisent que des lettres minuscules, des chiffres et des traits d'union. Ils retirent les accents, caractères spéciaux et espaces superflus. Cela améliore à la fois le SEO et l'expérience utilisateur · moteurs de recherche et humains peuvent lire l'URL et comprendre le contenu de la page.

D’où vient le mot, les salles de presse du XIXᵉ siècle

Le mot précède le web d’un siècle. Dans les salles de composition à l’ère du Linotype, chaque ligne de caractères était fondue en une seule bande de métal (un « slug ») d’environ trente picas de large et pesant à peu près douze onces de plomb. Le terme a ensuite glissé pour désigner le court identifiant qu’un rédacteur écrivait en haut d’un article pour l’étiqueter à travers la production : un handle d’un ou deux mots comme mayor-budget ou school-fire que journalistes, secrétaires de rédaction et imprimeurs pouvaient utiliser pour se référer à l’article sans taper le titre complet. Les guides de style d’AP et des grands quotidiens documentent encore cet usage.

Quand Movable Type, WordPress et la documentation Django des débuts ont adopté « slug » comme nom de champ au début des années 2000, ils empruntaient le terme de la salle de rédaction tel quel. La documentation de Django appelle le champ slug au moins depuis la sortie 0.91 en 2005, avec la définition désormais canonique : un court label ne contenant que des lettres, des chiffres, des underscores ou des tirets, généralement utilisé dans les URL. La métaphore tombe juste précisément parce que le slug en plomb fondu comme le slug d’URL sont tous deux des tokens courts, distincts et machine-friendly qui pointent vers une chose plus longue.

RFC 3986 et le jeu de caractères non réservés

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.

Comme le jeu non réservé est le seul garanti pour faire un aller-retour propre à travers tout parser d’URI jamais écrit, les générateurs de slugs convergent vers un pipeline quasi identique : mettre les caractères alphabétiques en minuscules, garder les chiffres, garder les tirets, remplacer le whitespace par un seul tiret, et soit retirer-soit-translittérer tout le reste. Underscore, point et tilde sont techniquement permis mais conventionnellement évités dans les slugs, le point entre en conflit avec les extensions de fichiers, le tilde se lit comme un répertoire home dans les anciennes conventions d’URL, et l’underscore perd face au tiret pour les raisons SEO traitées plus loin.

« Cool URIs Don’t Change », Berners-Lee, 1998

La note de style de 1998 de Tim Berners-Lee « Cool URIs Don’t Change », hébergée sur le site du W3C, est le morceau de philosophie de slug le plus cité jamais écrit. La phrase d’ouverture est célèbre : un cool URI est celui qui ne change pas. La note se lit ensuite comme une polémique contre les designs d’URL qui inscrivent des détails d’implémentation transitoires dans le path. Les à-ne-pas-faire recommandés ont façonné la pratique du slug depuis près de trente ans : ne pas mettre les extensions d’outil de rédaction dans l’URL (elles révèlent l’implémentation et cassent quand vous migrez ; ne pas mettre le statut dans l’URL) les pages sortent de « courant » mais l’URL ne devrait pas ; ne pas mettre les noms d’auteurs, les auteurs partent ; ne pas mettre de dates sauf si la date est fondamentale à la ressource ; ne pas mettre d’IDs de session, paramètres de query ou état de login dans une URL canonique.

Le slug (les mots descriptifs, sémantiques, en minuscules-tirets-mots) est exactement ce qui est autorisé dans une URI « cool ». Tout le reste est décoration structurelle qui ne devrait pas saigner dans l’adresse. Le design de permaliens de WordPress, le SlugField de Django et le to_param de Rails internalisent tous ce conseil : émettre une URL qui est le sens de la page, pas la mécanique de comment elle est servie.

Les tirets battent les underscores, et c’est documenté

Dans une interview WebmasterWorld de 2005, l’ingénieur Google Matt Cutts a dit que les tirets sont traités comme séparateurs de mots par le tokenizer de Google, tandis que les underscores sont des joiners de mots. Donc green-apples est lu comme les deux tokens green et apples, tandis que green_apples est lu comme l’unique token green_apples. Pour la requête « green apples », l’URL avec tirets correspondrait à la vérification mot-clé du titre ; l’URL avec underscores non. Cutts est revenu là-dessus en 2007 sur son blog et dans une vidéo Google Webmaster Help de 2011 sur YouTube (« Underscores vs. dashes in URLs »), réaffirmant le même conseil et notant que Google avait à un moment évalué de changer le comportement de l’underscore pour aussi agir comme séparateur, mais ne l’avait pas fait parce que cela aurait cassé trop d’URL existantes qui utilisaient intentionnellement les underscores comme joiners (__init__.py, noms de fonctions de programmation).

La page actuelle de Google « URL structure best practices for Google Search » recommande directement les tirets : une URL comme /green-dress.html est plus utile que /greendress.html, et vous devriez utiliser des tirets plutôt que des underscores. La recommandation est documentée en continu depuis plus de vingt ans. L’effet est petit par URL mais s’accumule sur un site de milliers de pages, et convertir les tirets en underscores n’a aucun avantage, il n’existe aucun scénario SEO où les underscores l’emportent. Tout guide de slug crédible se termine par le même conseil : utilisez des tirets.

Normalisation Unicode, comment NFD retire les accents

Le standard Unicode définit deux façons d’encoder beaucoup de caractères accentués : précomposé (un seul code point, où é est U+00E9) et décomposé (une lettre de base suivie de marques combinantes, où é est U+0065 plus U+0301, l’accent aigu combinant). Visuellement identiques, octet pour octet différents. Unicode Technical Standard #15 définit quatre formes de normalisation (NFC, NFD, NFKC, NFKD) et pour la génération de slugs, NFD est le levier. Si vous prenez une chaîne d’entrée, la normalisez en NFD, puis retirez tout code point dans la plage Unicode U+0300 à U+036F (le bloc Combining Diacritical Marks), vous récupérez la lettre ASCII de base. Café devient cafe, naïve devient naive, François devient Francois, niño devient nino, crème brûlée devient creme brulee.

NFD ne replie pas les caractères qui ne sont pas décomposables en base+marque. Le ß allemand (s dur) ne se décompose pas en ss sous NFD, il requiert une translittération explicite. Le ł polonais (l avec barre) ne se décompose pas en l. Le ø norvégien ne se décompose pas en o. Le þ islandais (thorn) et ð (eth) nécessitent des tables de correspondance. Les navigateurs supportent nativement String.prototype.normalize() depuis approximativement 2015 (Chrome 34, Firefox 31, Safari 10), c’est pourquoi même de petits utilitaires JavaScript de slugify peuvent faire le travail de retrait des diacritiques sans bibliothèque.

La famille de bibliothèques slugify, ce que chaque écosystème livre

django.utils.text.slugify() de Django est dans le framework Python depuis le début des années 2000. Il met en minuscules, retire les caractères absents de [A-Za-z0-9_-], et remplace le whitespace par des tirets. Depuis Django 1.9 (2015), un mot-clé allow_unicode=True bascule vers un mode Unicode-aware qui préserve les lettres non-ASCII. C’est l’implémentation de référence que tout le monde copie. En Node.js, @sindresorhus/slugify de Sindre Sorhus est le paquet slugify le plus téléchargé sur npm, avec des millions de téléchargements hebdomadaires, les fonctionnalités incluent des séparateurs lisibles, des remplacements personnalisables (de sorte que vous pouvez mapper & à and, @ à at), gestion Unicode et minuscules locale-aware (I pointé/non pointé turc, ß → ss allemand). Pour les utilisateurs Python n’utilisant pas Django, python-slugify de Val Neekman sur PyPI enveloppe la bibliothèque de translittération unidecode et ajoute un comportement spécifique au slug : découpage de mots par regex, caractères de remplacement, longueur max, retrait de mots vides.

D’autres écosystèmes suivent le même pattern. PHP a cocur/slugify de Cocur sur Packagist, utilisé par les plugins Laravel et Symfony, et Symfony lui-même livre un AsciiSlugger dans symfony/string depuis la version 5.0. Ruby on Rails utilise String#parameterize, intégré dans ActiveSupport au moins depuis Rails 1.0 ; le gem friendly_id superpose le suivi d’historique et la gestion de collisions. Go a gosimple/slug avec des tables de locale pour plus de quatre-vingts langues. Rust a le crate slug. Java a Apache Commons Text et slugify-jvm. La chose remarquable est à quel point l’API est convergente : chaîne en entrée, slug en sortie, avec la même poignée d’options, séparateur, longueur max, minuscules, locale. L’outil d’Absolutool s’inscrit dans la même famille mais tourne entièrement dans votre navigateur, sans bibliothèque à installer.

WordPress : 43 % du web fait tourner ce pipeline

WordPress est le plus grand système d’émission de slugs sur le web, il alimente environ 43 % de tous les sites web selon l’enquête W3Techs de 2026, donc ses conventions de slug sont effectivement les conventions de slug du web pour la plupart des lecteurs. Quand un post est sauvegardé, WordPress auto-génère le slug à partir du titre via sanitize_title() (qui appelle sanitize_title_with_dashes() pour le cas de réécriture par défaut) : minuscules, retire le HTML, décode les entités, remplace whitespace et la plupart de la ponctuation par des tirets, percent-encode les caractères dangereux, fusionne les tirets adjacents, retire les tirets de tête/fin. Si le résultat entre en collision avec le slug d’un post existant, WordPress ajoute -2, -3, et ainsi de suite. Le slug est éditable dans l’éditeur de post, une fois un post publié, changer le slug casse tout lien existant à moins que l’éditeur ne mette en place une redirection. WordPress historiquement ne translittérait pas les caractères non-ASCII par défaut ; il les percent-encodait, ce qui produisait les fameusement laides URL cyrilliques comme %D0%BF%D1%80%D0%B8... que des plugins comme Cyr-To-Lat ont été écrits pour corriger.

Au-delà du latin : translittération pour cyrillique, CJK, arabe

NFD ne gère que les caractères qui se décomposent en base ASCII + marques combinantes. Pour les scripts non latins, le pipeline de slug a besoin de translittération: un mapping de chaque caractère non latin vers son équivalent en script latin. La bibliothèque Python canonique est unidecode, à l’origine un portage du Text::Unidecode Perl de Sean M. Burke de 2001, qui mappe pratiquement tout caractère du Basic Multilingual Plane vers une chaîne ASCII « meilleure estimation » : Москва → Moskva, Αθήνα → Athena. Le fallback CJK est la partie controversée : unidecode utilise le pinyin mandarin pour tous les caractères CJK parce que le chinois a la plus grande couverture de caractères CJK, ce qui produit des romanisations absurdes pour le japonais (東京 → Dong Jing en pinyin, pas Tokyo). Des outils spécifiques au japonais comme pykakasi font le travail de conversion kanji + kana en rōmaji propre. La bibliothèque International Components for Unicode (ICU), maintenue par le Unicode Consortium et IBM, fournit une API Transliterator avec des jeux de règles nommés comme Russian-Latin/BGN, Greek-Latin/UNGEGN, et Han-Latin qui implémentent les standards officiels de romanisation. L’outil d’Absolutool se situe au bout léger : il replie les diacritiques latins via NFD et abandonne tout le reste. Un utilisateur voulant un titre russe ou chinois slugué peut faire tourner une étape de translittération séparée avant de coller le texte.

Limites de longueur d’URL, d’où vient la règle des 2000 caractères

Aucune limite de longueur n’est spécifiée par le RFC 3986 lui-même, la syntaxe d’URI est non bornée. Toute limite est pratique. Internet Explorer plafonnait historiquement les URL à 2 083 caractères (une limite dure intégrée au moteur Trident), ce qui est l’origine de la règle empirique largement citée des « 2 000 caractères ». Chrome, Firefox, Safari et Edge moderne supportent des URL jusqu’à environ 64 000 à 100 000+ caractères dans la barre d’adresse. LimitRequestLine d’Apache vaut par défaut 8 190 octets pour toute la ligne de requête ; large_client_header_buffers de nginx vaut par défaut 8 KB ; IIS vaut par défaut 4 096 octets pour l’URL et 2 048 pour la query string. RFC 9110 (HTTP/1.1, 2022) recommande au §4.1 qu’un serveur « ought to be capable of handling URIs of length 8 000 octets or longer » mais ne va pas jusqu’à imposer une limite supérieure. Pour les slugs, ce qui compte c’est qu’ils sont conventionnellement courts (trois à sept mots, trente à soixante caractères) pour le SEO et la partageabilité. John Mueller de Google a dit dans plusieurs Webmaster Hangouts que la longueur d’URL elle-même n’est pas un signal de classement, mais les longues URL peuvent être tronquées dans les snippets de résultats de recherche, nuire au taux de clic, et avoir l’air non professionnel dans les partages sociaux. La plupart des générateurs de slug exposent une option de longueur max pour cette raison ; celui-ci vaut par défaut illimité et vous laisse définir un plafond.

Retrait de mots vides : dense vs grammatical

Beaucoup de bibliothèques slugify offrent un retrait optionnel de mots vides, abandonner les courts mots communs (a, an, the, of, is, and, or, to, in, for, on) avant d’assembler le slug. La rationalisation est qu’ils n’ajoutent aucun signal SEO et bourrent l’URL. Donc « The Best Way to Make a Cup of Tea » devient best-way-make-cup-tea (5 tokens, 24 caractères) au lieu de the-best-way-to-make-a-cup-of-tea (10 tokens, 35 caractères). Le compromis : plus court et plus dense, mais avec un effondrement grammatical occasionnel (how-to-be-good dépouillé en how-good perd le sens) et un risque de retirer des mots qui portent réellement l’intention (art-of-war dépouillé en art-war). WordPress ne retire pas les mots vides par défaut (c’est un comportement de plugin opt-in) et la plupart des générateurs de slug modernes le laissent désactivé par défaut et le proposent comme une case à cocher. Yoast SEO pour WordPress signale un slug contenant des mots vides comme une recommandation mineure plutôt que comme une erreur. Ce générateur ne retire pas automatiquement les mots vides, au motif que l’éditeur connaît mieux l’intention du titre qu’une liste de mots statique. Si vous voulez les voir partir, éditez la sortie directement.

Collisions de slug : ce que les CMS font quand deux posts partagent un titre

Quand deux posts auto-génèrent le même slug, « My Post » et « My-Post! » produisent tous deux my-post: le système doit résoudre le conflit. Les stratégies les plus communes : un suffixe numérique (my-post-2, my-post-3) (prévisible, ne collisionne jamais, mais le suffixe ne porte aucune différence sémantique ; un préfixe de date (2026-04-27/my-post)) fonctionne bien pour le contenu de blog et est le défaut dans Jekyll, Hugo et la plupart des sites de news ; un suffixe d’auteur (my-post-jane) (utilisé par Medium et les blogs multi-auteurs ; un suffixe de hash aléatoire (my-post-a3f9)) utilisé par Stack Overflow, Notion et les systèmes de shortlinking, échangeant la lisibilité humaine contre l’unicité garantie ; ou édition manuelle au moment de la publication, éditorialement propre mais rarement le défaut parce que cela interrompt le flux. Le choix pragmatique pour la plupart des CMS est le suffixe numérique avec édition manuelle comme échappatoire. Les permaliens préfixés par date sont populaires pour le contenu ancré dans le temps où la date est une information significative.

Impact SEO : le slug comme signal mineur mais visible

La documentation de classement de Google liste la structure d’URL comme un signal de classement mineur, contenu de page, backlinks, signaux d’engagement utilisateur et fraîcheur portent tous plus de poids. Mais les mots d’URL contribuent, et ils contribuent visiblement. Les termes de slug apparaissent dans la ligne d’URL du snippet SERP sous le titre, ce qui influence le taux de clic même quand le slug lui-même n’est pas classé. Les termes de slug peuvent apparaître en gras dans la SERP s’ils correspondent à la requête de l’utilisateur, poids visuel supplémentaire. Le texte d’ancre des liens internes et externes vaut souvent par défaut l’URL quand aucun texte de lien n’est fourni, donc un slug sémantique devient le texte de lien et porte ses mots-clés à travers l’équité de lien entrant. Les tests A/B chez les éditeurs montrent constamment que des slugs descriptifs augmentent le CTR de pourcentages à un chiffre par rapport aux IDs opaques. L’étude de facteurs de classement 2020 de Backlinko (1,18 million de SERPs analysées) a trouvé que les URL courtes surperformaient légèrement les longues en haut des SERPs.

Il y a une exception à l’intuition « plus de mots-clés = mieux » : le bourrage de mots-clés. La mise à jour Exact-Match Domain (EMD) de septembre 2012 a spécifiquement réduit le crédit pour les domaines et slugs exact-match de basse qualité (cheap-life-insurance.com/buy-cheap-life-insurance), et Google a continué à déprécier le bourrage de mots-clés dans les URL depuis. Le constat 2026 : la présence de mots-clés dans le slug aide modestement ; le bourrage de mots-clés nuit. Le plus grand gain SEO d’un slug est de ne pas le changer après publication. Les liens entrants s’accumulent vers une URL. L’autorité de page se compose au niveau de l’URL. Une redirection 301 préserve la plupart mais pas toute l’équité de lien, et seulement si l’éditeur met effectivement la redirection en place, beaucoup ne le font pas. Le conseil « Cool URIs Don’t Change » de Berners-Lee a des conséquences SEO directes : chaque changement de slug, même avec une redirection, coûte une petite quantité d’autorité qui prend du temps à récupérer.

Bonnes pratiques SEO pour les slugs

Questions fréquentes

Prend-il en charge les caractères accentués ?

Oui. Le générateur utilise la normalisation Unicode (NFD) pour retirer les accents. Par exemple, « cafe » reste « cafe » tandis que « café » devient également « cafe ». Cela garantit des slugs propres, en ASCII pur.

Faut-il utiliser des traits d'union ou des traits bas ?

Les traits d'union sont recommandés pour le SEO. La documentation officielle de Google confirme que les traits d'union dans les URL sont traités comme des séparateurs de mots, alors que les traits bas ne le sont pas. Ainsi « mon-article » est lu comme deux mots, tandis que « mon_article » n'en forme qu'un.

Que se passe-t-il avec les emoji et symboles ?

Les emoji ne sont pas dans le jeu de caractères non réservés des URL, et NFD ne les décompose pas, ils n’ont pas d’équivalent latin. Ce générateur les abandonne. D’autres outils percent-encodent les emoji (transformant un seul caractère en une longue chaîne comme %F0%9F%94%A5), ce qui marche techniquement dans les navigateurs modernes mais produit des URL illisibles dans les analytics, partages sociaux et previews d’e-mail. La plupart des guides de slug recommandent de retirer entièrement les emoji ; si vous voulez les préserver, percent-encodez-les en amont de l’étape de slug.

Va-t-il sluguer des titres russes, chinois ou arabes ?

Pas tout seul. NFD ne replie que les caractères accentués en script latin ; il ne peut pas translittérer les scripts cyrillique, grec, arabe, hébreu ou CJK en latin. Coller un titre russe ou chinois dans cet outil abandonnera ces caractères et produira un slug vide ou quasi vide. Le bon workflow est de faire tourner une étape de translittération d’abord (unidecode de Python, le paquet npm transliteration de JavaScript, ou les conventions de romanisation de Wikipédia) et coller le résultat romanisé ici. Pour le japonais spécifiquement, utilisez un outil kana-aware comme pykakasi : les translittérateurs CJK génériques appliquent le pinyin mandarin et produisent Dong Jing pour 東京 plutôt que Tokyo.

Et si j’ai besoin de changer un slug après publication ?

Mettez en place une redirection 301 de l’ancienne URL vers la nouvelle avant de changer le slug. Un 301 (« Moved Permanently ») préserve la plupart de l’équité de lien qui s’est accumulée vers l’ancienne URL et dit aux crawlers et navigateurs de mettre à jour leurs marque-pages. Sans redirection, tout lien entrant existant se casse et vous perdez l’autorité de page que ces liens représentaient. Même avec une redirection, vous perdez une petite quantité d’équité qui prend des semaines ou des mois à récupérer. La maxime de Berners-Lee (cool URIs don’t change) est en partie esthétique, en partie une vérité SEO : chaque changement de slug coûte quelque chose, donc cela vaut la peine de bien faire le slug du premier coup.

Y a-t-il une longueur de slug recommandée ?

La convention est de trois à sept mots, environ trente à soixante caractères. Assez long pour être descriptif, assez court pour que le snippet SERP de Google ne le tronque pas et que les humains puissent saisir le sujet en un coup d’œil. Il n’y a pas de maximum technique dur (le RFC 3986 n’en spécifie pas et les navigateurs modernes gèrent des URL dans les dizaines de milliers de caractères) mais Apache, nginx et IIS imposent des plafonds pratiques dans la gamme des kilo-octets, et la règle hérité des « 2 000 caractères » d’Internet Explorer est encore citée comme un plafond cross-platform sûr. L’option Longueur Max ici vous laisse plafonner la sortie ; la mettre à 0 signifie illimité.

Mes textes sont-ils stockés ou envoyés quelque part ?

Non. La transformation s’exécute entièrement dans votre navigateur en utilisant la méthode String.prototype.normalize() intégrée de JavaScript (supportée depuis Chrome 34, Firefox 31, Safari 10, environ 2015). Rien n’est téléversé, aucune API n’est appelée, aucun log n’est écrit. Vous pouvez le vérifier en ouvrant l’onglet Réseau des DevTools de votre navigateur pendant que vous générez des slugs, il n’y a aucune requête sortante. La page est sûre pour des slugs dérivés de titres non publiés, documentation interne, posts brouillon ou tout autre contenu que vous ne voulez pas voir quitter votre appareil.

Outils associés

Encodeur / décodeur d'URL

Encodez ou décodez des URL et composants d'URI.

Convertisseur de casse

Convertissez du texte entre différentes casses.

Compteur de mots

Comptez mots, caractères et temps de lecture.