Config JSON

URL

À quoi sert JSON vers URL ?

Tu as un objet JSON qui décrit les morceaux d'un endpoint HTTP — protocole, host, chemin, paramètres de requête, hash — et tu en as besoin sous forme d'une chaîne URL unique que fetch(), curl ou ton client HTTP peut avaler. Colle le JSON à gauche, récupère l'URL assemblée et encodée à droite. C'est la même direction que chaque fixture de test backend, chaque exemple OpenAPI et chaque fichier de config doit finir par produire.

L'outil utilise le constructeur URL natif du navigateur et URLSearchParams pour assembler l'URL, donc l'encodage est exactement celui que définit le standard URL WHATWG et exactement ce qu'enverrait un vrai navigateur. Les espaces dans la query deviennent +, les crochets deviennent %5B/%5D, accents et emojis sont encodés en pourcentage UTF-8. Les clés de requête répétées sont gérées via un tableau — "tag": ["red", "blue"] émet tag=red&tag=blue.

Cette page existe parce que la plupart des projets stockent déjà des URLs sous forme JSON quelque part — fichiers d'environnement, collections Postman, fixtures Cypress, specs OpenAPI, valeurs Helm. Quand tu as besoin de ce JSON sous forme de chaîne URL pour un script ou un curl ponctuel, le recoudre à la main est l'endroit où se cachent les bugs. La conversion suit la RFC 3986 pour la syntaxe URL et accepte du JSON standard selon la RFC 8259 en entrée. Tout tourne en local — le JSON et l'URL ne quittent jamais ton navigateur. Le sens inverse vit sur URL vers JSON.

Comment convertir du JSON en URL

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

Colle une config JSON ou charge l'exemple

Dépose à gauche un objet JSON décrivant les parties de l'URL. protocol et host sont les seuls champs obligatoires ; tout le reste est optionnel. Clique sur Exemple pour charger un endpoint e-commerce réaliste avec plusieurs paramètres de requête 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 optionnels : port, username, password, pathname, searchParams, hash. Dans searchParams, une chaîne donne une seule valeur ; un tableau donne des clés répétées. La syntaxe JSON est parsée avec JSON.parse — pas de commentaires, pas de virgules finales.

Lis l'URL assemblée

Le panneau de droite se met à jour pendant que tu tapes. Tu verras l'URL complète — https://api.shop.example.com/v1/orders?customer=Ava+Chen&status=active&total%5Bgte%5D=49.99&page=2#summary — avec chaque partie encodée comme le standard URL le définit. Glisse-la directement dans un appel fetch(), une commande curl, un test Postman ou un fichier de config qui attend une seule chaîne URL.

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 avec une nouvelle config.

Quand tu vas vraiment t'en servir

Transformer des exemples OpenAPI en commandes curl exécutables

Les specs OpenAPI décrivent les serveurs comme {url, variables} et les opérations comme des chemins avec parameters. Composer la vraie URL à partir de ces morceaux à la main pour un curl ponctuel, c'est pénible — substituer les variables de chemin, encoder les paramètres, gérer le slash final. Mets le JSON déjà fusionné ici, copie l'URL, colle-la dans curl. La forme fusionnée correspond à ce que décrit le server-object OpenAPI.

Construire des URLs depuis des variables d'environnement éclatées

Une appli 12-factor stocke les morceaux d'URL en variables d'env séparées : API_HOST, API_PORT, API_BASE_PATH, API_TOKEN_PARAM. Pour produire l'URL complète d'un curl de vérification pendant un incident, tu les rassembles. Colle la forme JSON dans la page, récupère l'URL, lance-la. Plus rapide que de scripter ça en bash et sans risque d'oublier d'encoder un token contenant +.

Fixtures Cypress et Playwright qui stockent des URLs en objets

Les fixtures de test stockent souvent les URLs de requête sous forme structurée pour pouvoir asserter sur les morceaux individuels (le path param orderId, le query param page). Quand le fixture doit aussi faire un vrai appel HTTP (par exemple pour seeder via cy.request ou page.goto), la forme structurée doit redevenir une chaîne. JSON vers URL transforme l'objet fixture sauvegardé par Marco Rivera en l'URL que le harness de test peut taper.

URLs de webhook assemblées depuis des configs par tenant

Les systèmes multi-tenant stockent des configs de webhook par client : {host: "hooks.tenant-a.example.com", pathname: "/orders/ORD-1001/notify", searchParams: {token: "..."}}. Le dispatcher lit le JSON et a besoin d'une chaîne URL pour faire son POST. Même conversion que cette page fait, juste à l'exécution. Sers-toi de la page pour vérifier que l'URL que ton code va produire correspond à celle que le client a enregistrée.

Questions fréquentes

Quelle différence avec la page URL Builder ?

Même moteur, cadrage différent. URL Builder est pour le cas où tu t'assois pour assembler une URL à partir de zéro — tu composes une requête. JSON vers URL est pour le cas où le JSON existe déjà quelque part (une config, une spec OpenAPI, un fixture, un split de variables d'env) et tu dois le convertir en la chaîne URL qu'un bout de code attend. Choisis le cadrage qui correspond à ce que tu fais — la sortie est identique.

Mon JSON stocke l'URL différemment — je peux utiliser n'importe quelle forme ?

Il faut les noms de parties URL du standard WHATWG : protocol, host, port, username, password, pathname, searchParams (objet), hash. Si ton JSON utilise d'autres clés (scheme, baseUrl, query, fragment), renomme-les d'abord. La forme reflète ce que new URL(...) expose et ce que la spec URL définit, donc tu t'alignes sur le même modèle que fetch et Node utilisent en interne.

Comment envoyer un paramètre de requête deux fois (p.ex. ?tag=red&tag=blue) ?

Utilise un tableau comme valeur : "tag": ["red", "blue"]. Le convertisseur émet tag=red&tag=blue dans l'ordre fourni. C'est exactement comme URLSearchParams gère les clés répétées et c'est ce que la plupart des serveurs (Express, Rails, ASP.NET) attendent pour les query params en mode tableau.

Pourquoi mon espace devient + au lieu de %20 ?

Les espaces dans la partie query sont encodés 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 selon la RFC 3986 et tous les serveurs décodent l'une comme l'autre. Si ton serveur n'accepte que %20 dans la query, le bug est côté serveur.

Je peux inclure des identifiants (user/password) dans l'URL ?

Oui — mets "username" et "password" dans le JSON. Ils apparaîtront avant le host sous la forme user:pass@host. La RFC 3986 §3.2.1 déconseille de faire ça dans des URLs de production parce qu'ils finissent dans l'historique navigateur, les logs serveur et les caches de proxy — ok pour un test local rapide, pas ok dans des configs partagées.

L'URL quitte-t-elle un jour mon navigateur ?

Non. Le parsing du JSON c'est JSON.parse dans ton onglet ; l'assemblage de l'URL c'est new URL(...) dans ton onglet ; aucun des deux n'appelle un serveur. Pas d'upload, pas de logging. Tu peux ouvrir la page une fois avec une connexion, te déconnecter et continuer à l'utiliser depuis le cache.

Autres outils URL et JSON

JSON vers URL est la moitié de l'aller-retour. Voici le reste de la trousse :