Constructeur d'URL
Assemble une URL depuis une config JSON — encodage géré, clés répétées prises en charge
Config (JSON)
URL
Qu'est-ce que le Constructeur d'URL ?
Donne-lui un objet JSON décrivant les parties d'une URL — protocole, hôte, chemin, paramètres de requête, hash — et l'outil te rend l'URL assemblée, correctement pourcent-encodée. Sous le capot il utilise l'API URL native du navigateur, donc la sortie correspond exactement à ce qu'un navigateur produirait si tu construisais l'URL toi-même en JavaScript.
Pourquoi ça existe : construire une URL à la main, c'est là que les bugs se cachent. Tu oublies d'encoder un espace dans un nom client, tu double-encodes un slash déjà encodé, tu mélanges ? et &, tu perds une valeur parce que tu as utilisé + au lieu de %20. La spec URL du WHATWG définit exactement une bonne réponse pour chaque entrée, et c'est ce que tu obtiens ici. Les clés de requête répétées (par ex. tag=red&tag=blue) sont gérées en passant un tableau — la même forme qu'accepte URLSearchParams.
Tout tourne dans ton navigateur. La config JSON et l'URL assemblée ne quittent jamais ta machine. Les règles d'encodage viennent directement du RFC 3986 et des raffinements WHATWG par-dessus. Combine-le avec le Parseur d'URL quand tu veux faire un aller-retour d'une URL via un formulaire structuré.
Comment utiliser le Constructeur d'URL
Trois étapes. Chacune correspond à un bouton sur cette page.
Colle une config JSON
Colle un objet JSON à gauche décrivant les parties de l'URL. protocol et host sont obligatoires ; le reste est facultatif. Clique sur Exemple pour charger un cas réaliste avec plusieurs paramètres et un hash :
{
"protocol": "https",
"host": "api.shop.example.com",
"pathname": "/v1/orders",
"searchParams": {
"customer": "Ava Chen",
"status": "active",
"total[gte]": "49.99",
"page": "2"
},
"hash": "summary"
}Champs facultatifs : port, username, password, hash. À l'intérieur de searchParams, une chaîne = une valeur ; un tableau = des clés répétées.
Lis l'URL assemblée
Le panneau de droite affiche la chaîne URL assemblée. Les espaces deviennent + dans la query, les crochets deviennent %5B/%5D, le chemin est normalisé — exactement l'encodage défini par le standard URL. Mise à jour pendant que tu tapes.
Copie ou télécharge
Clique sur Copier pour envoyer l'URL dans ton presse-papiers, ou Télécharger pour la sauvegarder en fichier texte. Utilise Effacer sur le panneau d'entrée pour repartir de zéro.
Quand tu t'en servirais vraiment
Construire des fixtures de test pour un client HTTP
Tu écris un test qui tape sur /v1/orders avec huit paramètres, dont deux contenant des espaces et un répété. Taper l'URL encodée à la main dans le test, c'est l'erreur garantie. Construis-la depuis un objet JSON que tu copies d'un vrai log de requête, colle l'URL résultante dans l'assertion. Fini.
Construire des URLs d'autorisation OAuth
Les URLs d'autorisation OAuth empilent client_id, redirect_uri, scope, state, response_type et code_challenge dans la query string. Le RFC 6749 exige ces noms exacts et un redirect_uri déjà encodé une fois avant que toute l'URL soit ré-encodée. Le constructeur s'en occupe de façon transparente — tu lui donnes les valeurs brutes, il fait ce qu'il faut.
Générer des URLs analytics ou de partage dans un script
Quand tu génères une URL de campagne avec des paramètres UTM, les valeurs viennent souvent d'un tableur où utm_campaign contient des espaces, des esperluettes et l'emoji occasionnel. Laisser le constructeur d'URL gérer l'encodage est plus sûr qu'un template de chaîne. La sortie est identique à ce que produirait le module URL de Node.
Reproduire un bug depuis un ticket support
Un client signale qu'une recherche avec q=résumé writer renvoie 500 sur l'API. Tu veux reproduire la requête exacte. Construis l'URL depuis du JSON, puis curle-la. L'accent sur le e et l'espace sont encodés exactement comme le navigateur les aurait envoyés — sans deviner.
Questions fréquentes
Quelle différence entre le Constructeur d'URL et concaténer des chaînes moi-même ?
L'encodage. https://api.example.com/orders?customer=Ava Chen n'est pas une URL valide — l'espace la casse. Le constructeur utilise URLSearchParams en interne, qui encode cet espace en + dans la query et en %20 dans le chemin. La concaténation à la main se trompe sur l'un ou l'autre tôt ou tard.
Comment envoyer un paramètre deux fois (par ex. ?tag=red&tag=blue) ?
Utilise un tableau comme valeur : "tag": ["red", "blue"]. Le constructeur émet tag=red&tag=blue dans l'ordre fourni. Conforme à la spec URLSearchParams.
Faut-il inclure le deux-points après le protocole (https:) ou juste https ?
Les deux marchent. Le constructeur normalise "protocol": "https" comme "protocol": "https:" en https:. Pareil pour http, ftp, mailto et les schémas personnalisés.
Puis-je inclure des identifiants (utilisateur/mot de passe) dans l'URL ?
Oui — mets "username" et "password" dans la config. Ils apparaîtront avant l'hôte sous la forme user:pass@host. Sache que le RFC 3986 §3.2.1 met en garde contre cet usage en prod parce qu'ils finissent dans l'historique du navigateur, les logs serveur et les caches proxy.
Pourquoi mon espace devient + au lieu de %20 ?
Les espaces dans la partie query sont encodés typiquement en + selon les règles application/x-www-form-urlencoded — c'est ce qu'émet URLSearchParams. Les espaces dans le chemin sont encodés en %20. Les deux sont valides ; les serveurs décodent les deux formes. Si ton serveur est cassé et ne gère que %20, ton problème est plus gros que cet outil.
Autres outils URL & JSON
Construire est une direction. Voici ce qui s'associe naturellement :