URL

Composants

C'est quoi l'Analyseur d'URL ?

Colle une URL et l'outil la coupe en morceaux qui t'intéressent vraiment — protocole, hôte, port, chemin, paramètres de requête, hash. La sortie est en JSON, donc tu peux la copier direct dans une fixture de test, un log de debug, ou n'importe où il te faut les composants sous forme structurée. Le parser suit le standard URL WHATWG, c'est ce que tous les navigateurs modernes utilisent en interne.

Pourquoi un parser ? Parce que lire une URL longue avec cinq paramètres de requête encodés en pourcentage et un fragment de hash, c'est pénible. Le navigateur sait déjà faire ça via l'API URL, mais tu n'as pas de surface rapide coller-et-voir pour ça. C'est ce que fait cet outil. Les paramètres de requête sont aussi décodés — %20 devient un espace, %5B devient [, les clés répétées deviennent un tableau — même comportement que URLSearchParams.

Tout tourne dans ton navigateur. Pas d'upload, pas de serveur, pas de logs. Le parsing d'URL est déterministe — pas d'IA, pas de devinette, juste le même algorithme défini par le RFC 3986 et raffiné par la spec WHATWG.

Comment utiliser l'Analyseur d'URL

Trois étapes. Chacune correspond à un bouton sur cette page.

Colle une URL ou charge l'exemple

Lâche une URL dans le panneau de gauche. Clique sur Exemple pour charger un cas réaliste avec encodage pourcent, clés de requête répétées et fragment de hash. URL d'exemple :

https://api.shop.example.com/v1/orders?customer=Ava%20Chen&status=active&total%5Bgte%5D=49.99&page=2#summary

Tout ce que le constructeur URL accepte fonctionne — y compris <code>file://</code>, <code>mailto:</code>, les schémas personnalisés, les hôtes IPv6, et les userinfo (<code>user:pass@host</code>).

Lis les composants

Le panneau de droite affiche l'URL parsée en JSON : protocol, host, port, pathname, pathSegments (le chemin découpé en tableau), searchParams (paires clé-valeur décodées, avec des tableaux pour les clés répétées) et hash. Mis à jour pendant que tu tapes.

Copie ou télécharge

Clique sur Copier pour envoyer le JSON dans ton presse-papiers, ou Télécharger pour le sauver en fichier .json. Minifier compacte le JSON sur une seule ligne si tu en as besoin pour une ligne de log. Utilise Effacer sur le panneau d'entrée pour repartir de zéro.

Quand tu vas vraiment t'en servir

Déboguer les redirections et URLs d'analytics

Une URL avec douze paramètres de requête venant d'une redirection de tracking pub est illisible dans la barre d'adresse. Colle-la ici pour voir les paramètres un par ligne, décodés, avec le paramètre url de destination complètement déballé. Ça se marie bien avec le strip de trackers de notre Nettoyeur d'URL (quand il sera dispo).

Inspecter les URLs de webhooks et callbacks OAuth

Les callbacks OAuth et payloads webhook bourrent la query string d'état. Le découper rend évident s'il manque le token state, si le code est tronqué, ou si le redirect_uri est encodé deux fois. Le RFC 6749 exige ces params et l'outil les fait tous remonter d'un coup.

Fabriquer des fixtures de test

Quand tu écris des tests contre une URL, tu la veux en général sous forme d'objet structuré, pas de chaîne. Colle l'URL, copie le JSON, balance-le dans ton fichier de fixtures. Ça t'évite de taper protocol: 'https:' à la main pour la cinquième fois aujourd'hui.

Vérifier les tickets de support client

"Ça a planté quand j'ai cliqué sur ce lien" — le lien fait 400 caractères avec des slashes encodés deux fois. Le parser te montre exactement ce que verrait le navigateur, y compris si %252F veut dire un %2F littéral ou un séparateur de chemin réencodé en passant par un proxy.

Questions fréquentes

Ça marche avec les URLs relatives ?

Non — le constructeur URL a besoin d'une URL absolue (avec un protocole comme https:// ou file://). Pour les URLs relatives, ajoute d'abord une base comme https://example.com, puis enlève-la du résultat. La spec WHATWG décrit la forme à deux arguments (new URL(relative, base)) utilisée en interne par les navigateurs.

Comment ça gère les clés de requête répétées ?

Les clés répétées se replient en tableau. Donc ?tag=red&tag=blue devient "tag": ["red", "blue"] en sortie. Ça correspond à la façon dont la plupart des frameworks serveur (Express, FastAPI, ASP.NET) parsent les query strings.

Et la notation crochets comme ?items[]=1&items[]=2 ?

Le parser traite les crochets comme partie de la clé — tu verras donc "items[]": ["1", "2"]. C'est honnête par rapport aux octets sur le câble. Si tu as besoin d'un décodeur spécifique à un framework (PHP, Rails, qs.js), fais le post-traitement sur la sortie parsée.

C'est sûr de coller des credentials dans une URL (user:pass@host) ici ?

Le parsing se fait entièrement dans ton navigateur — l'URL ne quitte jamais ta machine. Cela dit, mettre des credentials dans une URL est généralement déconseillé (le RFC 3986 §3.2.1 note les risques de sécurité), et la plupart des navigateurs les retirent silencieusement. Si tu en colles, les champs username et password apparaîtront dans la sortie.

Ça gère les noms de domaine internationalisés (IDN) ?

Le constructeur URL du navigateur gère les domaines IDN, mais la sortie peut afficher la forme Punycode (xn--...) plutôt que la forme Unicode. C'est comme ça que l'URL serait vraiment envoyée sur le câble. Si tu as besoin de convertir entre les deux, un outil Punycode dédié arrivera bientôt dans cette section.

Pourquoi la sortie s'appelle "Composants" et pas "JSON" ?

C'est bien du JSON — mais le cadrage compte. La sortie, ce sont les morceaux de l'URL, structurés. Si tu vois la page comme un "convertisseur URL → JSON", tu rates le truc : la valeur est dans le découpage, pas dans le format.

Autres outils URL et JSON

Le parsing, c'est une opération. Voici ce qui se marie naturellement avec :