Constructeur d'URL, gratuit

Anatomie d'une URL, composant par composant

La grammaire qui définit chaque URL sur le web vit dans la RFC 3986 « Uniform Resource Identifier (URI): Generic Syntax » (Berners-Lee, Fielding, Masinter, janvier 2005). Les navigateurs utilisent en fait une variante légèrement plus tolérante définie dans le WHATWG URL Living Standard. Les deux s'accordent sur les composants :

• Schéma: https, http, ftp, mailto, data, tel, sms, magnet, plus les schémas d'application personnalisés (myapp://). RFC 3986 exige des minuscules ; WHATWG canonise. Le registre des schémas URI de l'IANA contient la liste officielle des schémas enregistrés.
• Autorité: userinfo@host:port. La forme d'identifiants intégrés user:password@ est dépréciée pour des raisons de sécurité : Chrome 64 (janvier 2018) bloque les chargements de sous-ressources avec des identifiants dans l'URL parce qu'ils permettaient des astuces de phishing.
• Hôte: un nom de domaine ou un littéral IP. Les noms de domaine internationalisés comme президент.рф sont convertis en ASCII via Punycode (RFC 3492, mars 2003) : cet exemple devient xn--d1abbgf6aiiy.xn--p1ai. Les navigateurs effectuent la conversion de manière transparente pour l'affichage.
• Port: inclus uniquement quand non par défaut pour le schéma. Valeurs par défaut : 80 (http), 443 (https), 21 (ftp), 22 (ssh), 25 (smtp), 5432 (postgres), 3306 (mysql), 6379 (redis).
• Chemin: segments séparés par des barres obliques. Chaque segment encode en pourcentage tout ce qui se trouve en dehors de l'ensemble pchar défini dans la RFC 3986 §3.3. Les segments-points . et .. ont une sémantique de suppression (§5.2.4).
• Requête: par convention paires clé-valeur séparées par &, mais la RFC 3986 dit seulement « chaîne opaque après ? ». La convention est formalisée dans l'algorithme application/x-www-form-urlencoded du WHATWG.
• Fragment: tout après #. Jamais envoyé au serveur. Utilisé par les routeurs d'application monopage, les ancres de liens, et les jetons de flux implicite OAuth.

Encodage pourcent : le piège + versus %20

RFC 3986 §2.3 définit les caractères non réservés qui n'ont jamais besoin d'encodage : A-Z a-z 0-9 - . _ ~. Tout le reste, quand il apparaît comme données à l'intérieur d'un composant d'URL, devient %XX où XX est la valeur hexadécimale de l'octet. Les caractères UTF-8 multi-octets s'étendent en plusieurs triplets pourcent : é (U+00E9, UTF-8 C3 A9) s'encode en %C3%A9. Le piège classique est le caractère espace : dans un chemin ou fragment d'URL régulier, l'espace s'encode en %20 ; dans les chaînes de requête encodées en formulaire (l'algorithme application/x-www-form-urlencoded partagé par les formulaires HTML et le sérialiseur de chaînes de requête WHATWG), l'espace s'encode en +. Un serveur décodant des données de formulaire reconvertit + en espace ; un serveur traitant la requête comme une URI générique ne le fait pas. Mélanger les deux conventions corrompt silencieusement les données. Le modèle sûr en JavaScript : utilisez new URLSearchParams pour les requêtes et encodeURIComponent pour les valeurs individuelles ; la conformité à la spec est prise en charge pour vous.

Là où vous avez vraiment besoin d'un constructeur d'URL

• Liens marketing balisés UTM pour Google Analytics (Urchin Tracking Module, dans GA depuis 2005) : les cinq paramètres canoniques sont utm_source, utm_medium, utm_campaign, utm_content, utm_term, tous en minuscules selon les directives de Google.
• Requêtes d'autorisation OAuth 2.0 (RFC 6749, octobre 2012) : la spec impose response_type, client_id, redirect_uri, scope, state comme paramètres de requête sur l'endpoint d'autorisation.
• Liens profonds mobiles : un schéma app:// que l'OS achemine vers votre application installée au lieu du navigateur, ou un Android App Link / iOS Universal Link servi depuis votre domaine.
• Tests de clients API : https://api.example.com/v2/users?expand=projects&since=2024-01-01. Taper ces URL à la main échoue constamment à l'étape « espace dans une valeur ».
• Buster de cache CDN : ?v=2026-05-12-1 ajouté aux URL d'assets statiques pour qu'un déploiement invalide la version mise en cache. La chaîne de requête fait partie de la clé de cache.
• Services de transformation d'image (Cloudinary, imgix, Cloudflare Images) : la transformation est encodée comme paramètres de requête ou segments de chemin. Un appel typique ressemble à ?w=800&q=85&fm=webp.
• Modèles d'email où la page d'atterrissage lit les paramètres via JS, combinant souvent les balises UTM avec un token ou uid unique pour le suivi par destinataire.

Erreurs courantes

• Oublier d'encoder & à l'intérieur d'une valeur. Une valeur « chats & chiens » laissée naïvement dans ?espèces=chats & chiens devient une clé espèces avec valeur chats plus une clé vide errante. Toujours passer par encodeURIComponent.
• Double-encodage. Appeler encodeURIComponent sur une chaîne déjà encodée transforme %20 en %2520. Facile quand une valeur passe à travers deux systèmes qui chacun « encodent défensivement ».
• Décalage de barre oblique finale. RFC 3986 dit que https://example.com/api et https://example.com/api/ sont des ressources différentes. La plupart des API REST les traitent de manière identique, mais certaines renvoient des redirections 308 ; choisissez une forme canonique et documentez-la.
• Mélanger + et %20. Les chaînes de requête encodées en formulaire utilisent + pour l'espace ; l'encodage pourcent générique utilise %20. Un chemin avec + littéral survit au copier-coller mais échoue quand un décodeur de formulaire le lit.
• Identifiants intégrés. https://user:pass@example.com est déprécié et bloqué pour les chargements de sous-ressources dans Chrome 64+. Utilisez l'en-tête Authorization.
• Usurpation IDN. Le cyrillique « а » (U+0430) est visuellement identique au latin « a ». Les navigateurs affichent Punycode quand un domaine mélange les scripts, mais une URL construite manuellement pointant vers аpple.com (cyrillique а) ouvre un site différent de apple.com. Utilisez Punycode (xn--...) pour la sécurité, ou restez en ASCII.
• Ajouter // après des schémas qui ne l'utilisent pas. mailto:, tel:, sms:, magnet: sautent tous le // et vont directement au chemin. mailto:user@example.com est correct ; mailto://... ne l'est pas.

Plus de questions fréquentes

Quelle est la longueur maximale d'une URL ?

RFC 3986 ne fixe aucune limite. En pratique : les navigateurs plafonnent à environ 2 000 caractères pour la barre d'adresse (Internet Explorer 11 était à 2 083 ; Chrome et Firefox tolèrent plus mais tronquent l'affichage) ; la plupart des CDN et proxies plafonnent à 4 096 ou 8 192 ; les serveurs comme Apache et Nginx par défaut à 8 192 octets pour la ligne de requête. Si vous avez besoin de plus de 2 000 caractères, passez au corps POST.

Puis-je inclure le même paramètre de requête plusieurs fois ?

Oui. ?tag=red&tag=blue&tag=green est valide. Comment le serveur l'interprète dépend du framework : Express / Node.js parse à req.query.tag = ['red', 'blue', 'green'] ; PHP nécessite la convention de crochets ?tag[]=red&tag[]=blue ; Rails parse à un tableau si vous utilisez les crochets tag[]. La méthode URLSearchParams.getAll('tag') renvoie toujours toutes les valeurs sous forme de tableau quel que soit le style de crochets.

Les paramètres de requête affectent-ils le SEO ?

Les paramètres de suivi (UTM, fbclid, gclid) n'affectent généralement pas le classement de recherche organique. Le risque est l'indexation de contenu dupliqué : une URL balisée et sa version propre ressemblent à deux pages différentes pour un crawler. La solution est une balise <link rel="canonical" href="clean-url"> pointant chaque variante balisée vers la même URL canonique.

Qu'est-ce qu'un modèle URI, et devrais-je en utiliser un ?

RFC 6570 (mars 2012) définit les modèles URI : une syntaxe pour des URL paramétrées avec des espaces réservés. Ils sont utilisés dans les specs OpenAPI / Swagger, JSON Hyper-Schema, et certaines API HATEOAS. Pour la construction d'URL au quotidien, la simple concaténation de chaînes via ce constructeur est plus simple ; les modèles URI brillent quand on documente une surface API et qu'on génère des SDK clients.

Quelque chose est-il envoyé à un serveur ?

Non. Chaque composant que vous tapez, l'encodage, et l'URL finale sont construits dans le JavaScript de votre navigateur. Aucun appel réseau n'est effectué pour assembler l'URL. Ouvrez l'onglet Réseau dans DevTools et essayez l'outil : vous verrez zéro requête sortante pendant la construction.