URL en JSON
Convertis n'importe quelle URL en un objet JSON structuré — prêt à coller dans une config, un fixture ou un test
URL
JSON
À quoi sert URL en JSON ?
Tu colles une URL à gauche, et à droite tu obtiens un objet JSON avec chaque morceau de l'URL nommé — protocol, host, pathname, searchParams, hash, tout. Le but n'est pas de regarder une fois et passer à autre chose. Le but, c'est de copier ce JSON là où il va vivre — un fichier de config, un fixture Jest, un environnement Postman, un manifeste YAML, un mock de requête pour tes tests. Les URLs en chaîne sont faciles à taper mais difficiles à valider ; les objets structurés, c'est l'inverse.
Sous le capot, c'est le même algorithme que tous les navigateurs utilisent via la URL API, qui implémente le WHATWG URL Standard. Les paramètres de requête sont décodés au passage — %20 devient un espace, %5B devient [, les clés répétées sont regroupées en tableau JSON — exactement le comportement de URLSearchParams. La sortie est ensuite formatée selon les mêmes règles JSON.stringify que tous les autres outils JSON du site.
Si tu veux juste regarder les morceaux d'une URL à l'écran — déboguer une redirection, jeter un œil à une chaîne de trackers — la page Analyseur d'URL est plus adaptée. Les deux pages font la même conversion ; celle-ci est cadrée pour le cas où le JSON lui-même est l'artefact que tu gardes. Tout reste local dans ton navigateur, pas d'upload, pas de logs. La conversion suit la RFC 3986 pour la syntaxe et la RFC 8259 pour la sortie JSON.
Comment convertir une URL en JSON
Trois étapes. Chacune correspond à un bouton de la page.
Colle une URL ou charge l'exemple
Dépose une URL dans le panneau de gauche. Clique sur Exemple pour charger une URL e-commerce réaliste avec encodage pour-cent, clés de requête répétées et fragment. Exemple :
https://api.shop.example.com/v1/orders?customer=Ava%20Chen&status=active&total%5Bgte%5D=49.99&page=2#summaryTout ce que le constructeur URL accepte fonctionne — <code>http://</code>, <code>https://</code>, <code>file://</code>, <code>mailto:</code>, hôtes IPv6 et userinfo.
Lis la sortie JSON
Le panneau de droite se met à jour pendant que tu tapes. Tu verras 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. Le champ href contient la forme canonique et normalisée de l'URL — utile quand tu dois vérifier que deux URLs sont équivalentes même si l'une avait un port par défaut ou une barre oblique finale.
Copie, télécharge ou minifie pour ton fixture
Clique sur Copier pour envoyer le JSON dans le presse-papiers, sur Télécharger pour le sauvegarder en url.json, ou sur Minifier pour le compacter sur une seule ligne pour un log ou un paramètre de requête. Effacer sur le panneau d'entrée remet les deux éditeurs à zéro.
Quand tu t'en sers vraiment
Construire des fixtures de requêtes HTTP
Quand tes tests vérifient une URL, le faire sur une chaîne est fragile — la casse, les ports par défaut, les barres obliques finales et l'ordre des paramètres font tous des dégâts. Convertis l'URL en JSON, mets l'objet dans ton fixture et vérifie champ par champ. Ça s'intègre proprement avec des libs comme Mock Service Worker ou Nock qui matchent sur la forme de l'URL.
Initialiser des clients d'API dans des fichiers de config
Une config YAML ou JSON qui stocke une URL de base sous forme de chaîne unique force chaque consommateur à la re-parser. La stocker déjà décomposée (host, port, basePath, defaultParams) rend la config auto-documentée et élimine toute une classe de bugs du genre "on a oublié la barre finale". Pratique pour les générateurs de SDK et l'outillage OpenAPI.
Documentation des callbacks OAuth et webhooks
Quand tu écris une doc qui montre "ton URL de callback ressemblera à ça", livrer un découpage JSON à côté de l'URL brute est beaucoup plus sympa pour le lecteur. Des standards comme la RFC 6749 exigent des paramètres de requête précis ; un format structuré rend "tu dois voir state ici" évident d'un coup d'œil.
Exports d'environnements Postman / Bruno / HTTPie
La plupart des clients d'API stockent les URLs sous forme d'objets décomposés en interne. Si tu importes des URLs anciennes dans une nouvelle collection — par exemple, en migrant depuis un site de docs qui liste les endpoints en chaînes — les convertir d'abord en JSON te permet de scripter l'import au lieu de cliquer manuellement sur 200 endpoints.
Questions fréquentes
Quelle différence avec la page Analyseur d'URL ?
Même moteur, autre cadrage. Analyseur d'URL sert à inspecter — tu colles une URL longue, tu regardes les morceaux, tu décides ce qui cloche, tu fermes l'onglet. URL en JSON sert à prendre le résultat et l'utiliser ailleurs — un fichier de fixture, une config, un environnement Postman. La sortie JSON est identique ; le texte et les cas d'usage sont ajustés au workflow "je veux ça dans un fichier".
Pourquoi la sortie est en JSON et pas en YAML ou en littéral d'objet JS ?
JSON est le plus petit dénominateur commun — chaque langage, chaque système de config, chaque framework de tests le lit. Si tu as besoin de YAML, passe le JSON dans notre outil JSON en YAML. Si tu veux un littéral d'objet JS, JSON est déjà du JS valide — colle-le directement dans ton fichier .ts. La conversion suit la RFC 8259 pour que la sortie marche partout où JSON est accepté.
Comment les clés de requête répétées sont-elles représentées ?
Les clés répétées sont regroupées en tableau. ?tag=red&tag=blue devient "tag": ["red", "blue"]. C'est exactement comme ça qu'Express, FastAPI, ASP.NET, Spring et la plupart des frameworks parsent les query strings — et c'est ce que renvoie URLSearchParams.getAll().
Et les tableaux en notation crochets, comme ?items[]=1&items[]=2 ?
Les crochets sont gardés dans la clé — tu verras "items[]": ["1", "2"] dans la sortie. C'est une représentation fidèle des octets qui passent sur le réseau. Si ton framework (PHP, Rails, qs.js) a besoin que les crochets soient retirés ou développés en objet imbriqué, fais-le dans une étape de post-traitement sur le JSON.
Le JSON inclut-il le mot de passe si mon URL contient user:pass@host ?
Oui — les champs username et password apparaîtront dans la sortie s'ils sont dans ton URL. La conversion tourne entièrement dans ton navigateur, donc les identifiants ne quittent jamais ta machine. Cela dit, mettre des identifiants dans une URL est généralement une mauvaise idée (voir RFC 3986 §3.2.1), et tu voudras quasiment toujours les retirer avant de committer le JSON dans un repo.
Je peux convertir une liste d'URLs d'un coup ?
Pas sur cette page — chaque session convertit une seule URL. Si tu as une centaine d'URLs à traiter, le plus simple est de coller la structure de sortie de cette page dans un petit script et de boucler. Ou utiliser notre Formateur JSON après avoir scripté le batch toi-même. La conversion par lots côté UI est dans la roadmap mais pas encore livrée.
Autres outils URL & JSON
La conversion n'est qu'une opération. Voici ce qui se marie bien avec :