JSON-Config

URL

Was macht JSON zu URL?

Du hast ein JSON-Objekt, das die Bestandteile eines HTTP-Endpoints beschreibt — Protocol, Host, Pfad, Query-Parameter, Hash — und brauchst es als einzelnen URL-String, den fetch(), curl oder dein HTTP-Client schlucken kann. JSON links einfügen, fertig zusammengebaute und prozentkodierte URL rechts holen. Dieselbe Richtung, die jede Backend-Test-Fixture, jedes OpenAPI-Beispiel und jede Config-Datei früher oder später produzieren muss.

Verwendet den nativen URL-Konstruktor des Browsers und URLSearchParams, um die URL zusammenzubauen. Die Kodierung entspricht damit exakt dem, was der WHATWG-URL-Standard definiert und was ein echter Browser senden würde. Leerzeichen in der Query werden zu +, eckige Klammern zu %5B/%5D, Umlaute und Emojis werden UTF-8-prozentkodiert. Wiederholte Query-Keys gehen über ein Array — "tag": ["red", "blue"] erzeugt tag=red&tag=blue.

Diese Seite gibt es, weil die meisten Projekte URLs ohnehin irgendwo als JSON liegen haben — Environment-Files, Postman-Collections, Cypress-Fixtures, OpenAPI-Specs, Helm-Values. Wenn du dieses JSON für ein Skript oder einen Einmal-curl als echten URL-String brauchst, ist das Handzusammenbauen genau die Stelle, an der sich Bugs verstecken. Die Konvertierung folgt für die URL-Syntax dem RFC 3986 und akzeptiert auf der Eingabeseite Standard-JSON gemäß RFC 8259. Alles läuft lokal — JSON und URL verlassen deinen Browser nie. Die Gegenrichtung wohnt unter URL zu JSON.

JSON in eine URL umwandeln

Drei Schritte. Jeder entspricht einem Button auf dieser Seite.

JSON-Config einfügen oder Beispiel laden

Wirf links ein JSON-Objekt rein, das die URL-Teile beschreibt. protocol und host sind die einzigen Pflichtfelder; alles andere ist optional. Klick auf Beispiel, um einen realistischen E-Commerce-Endpoint mit mehreren Query-Parametern und Hash zu laden:

{
  "protocol": "https",
  "host": "api.shop.example.com",
  "pathname": "/v1/orders",
  "searchParams": {
    "customer": "Ava Chen",
    "status": "active",
    "total[gte]": "49.99",
    "page": "2"
  },
  "hash": "summary"
}

Optionale Felder: port, username, password, pathname, searchParams, hash. Innerhalb von searchParams ist ein String ein einzelner Wert; ein Array bedeutet wiederholte Keys. JSON-Syntax wird mit JSON.parse geparst — keine Kommentare, keine Trailing-Kommas.

Die zusammengebaute URL ablesen

Das rechte Panel aktualisiert sich beim Tippen. Du siehst die vollständige URL — https://api.shop.example.com/v1/orders?customer=Ava+Chen&status=active&total%5Bgte%5D=49.99&page=2#summary — mit jedem Teil so prozentkodiert, wie es der URL-Standard vorgibt. Übernimm sie direkt in einen fetch()-Aufruf, ein curl-Kommando, einen Postman-Test oder ein Config-File, das einen einzelnen URL-String erwartet.

Kopieren oder herunterladen

Klick auf Kopieren, um die URL in die Zwischenablage zu schicken, oder auf Herunterladen, um sie als Textdatei zu speichern. Mit Leeren im Eingabe-Panel startest du mit einer frischen Config neu.

Wann du das tatsächlich brauchst

OpenAPI-Beispiele in lauffähige curl-Kommandos verwandeln

OpenAPI-Specs beschreiben Server als {url, variables} und Operationen als Pfade mit parameters. Die echte URL aus diesen Teilen für einen Einmal-curl per Hand zusammenzusetzen ist fummelig — Pfadvariablen einsetzen, Query-Parameter kodieren, Trailing-Slash richtig hinkriegen. Geh mit dem zusammengeführten JSON hier rein, kopier die URL raus, in curl rein. Die zusammengeführte Form passt zu dem, was das OpenAPI-Server-Object beschreibt.

URLs aus auf Env-Vars verteilten Teilen bauen

Eine 12-Factor-App speichert URL-Teile in getrennten Env-Vars: API_HOST, API_PORT, API_BASE_PATH, API_TOKEN_PARAM. Um im Incident-Response-Modus die volle URL für einen Sanity-Check-curl zu produzieren, baust du sie zusammen. JSON-Form auf dieser Seite einfügen, URL holen, ausführen. Schneller als ein Bash-Skript und ohne das Risiko, einen Token mit + zu vergessen zu kodieren.

Cypress- und Playwright-Fixtures, die URLs als Objekte ablegen

Test-Fixtures speichern Request-URLs oft strukturiert, damit einzelne Teile (der orderId-Pfadparameter, der page-Query-Parameter) per Assert geprüft werden können. Wenn das Fixture zusätzlich einen echten HTTP-Aufruf braucht (z. B. Daten via cy.request oder page.goto seeden), muss die strukturierte Form wieder zum String werden. JSON zu URL macht aus Marco Riveras gespeichertem Fixture-Objekt die URL, die der Test-Harness ansprechen kann.

Webhook-URLs aus tenant-spezifischen Configs

Multi-Tenant-Systeme legen Webhook-Configs pro Kunde ab: {host: "hooks.tenant-a.example.com", pathname: "/orders/ORD-1001/notify", searchParams: {token: "..."}}. Der Dispatcher liest das JSON und braucht einen URL-String fürs POST. Dieselbe Konvertierung wie auf dieser Seite, nur zur Laufzeit. Nutz die Seite, um zu prüfen, ob die URL, die dein Code produzieren wird, mit der vom Kunden registrierten übereinstimmt.

Häufige Fragen

Was ist der Unterschied zur URL-Builder-Seite?

Gleiche Engine, andere Verpackung. Der URL Builder ist für den Fall, dass du dich hinsetzt, um eine URL von Grund auf zusammenzubauen — du komponierst einen Request. JSON zu URL ist für den Fall, dass das JSON irgendwo schon existiert (eine Config, eine OpenAPI-Spec, ein Fixture, ein Env-Var-Split) und du es in den URL-String umwandeln musst, den ein Stück Code erwartet. Such dir die Variante aus, die zu deiner Situation passt — die Ausgabe ist identisch.

Mein JSON speichert die URL anders — kann ich ein beliebiges Format nehmen?

Es braucht die WHATWG-URL-Teilnamen: protocol, host, port, username, password, pathname, searchParams (Objekt), hash. Wenn dein JSON andere Keys nutzt (scheme, baseUrl, query, fragment), benenne sie vorher um. Die Form spiegelt das wider, was new URL(...) exponiert und was die URL-Spec definiert — du richtest dich also an demselben Modell aus, das fetch und Node intern verwenden.

Wie sende ich denselben Query-Parameter zweimal (z. B. ?tag=red&tag=blue)?

Nutze ein Array als Wert: "tag": ["red", "blue"]. Der Konverter erzeugt tag=red&tag=blue in der angegebenen Reihenfolge. Das entspricht der Art, wie URLSearchParams wiederholte Keys behandelt, und ist das, was die meisten Server (Express, Rails, ASP.NET) für Array-Style-Query-Parameter erwarten.

Warum wird mein Leerzeichen zu + statt zu %20?

Leerzeichen im Query-Teil werden gemäß den application/x-www-form-urlencoded-Regeln als + kodiert — genau das gibt URLSearchParams aus. Leerzeichen im Pfad werden als %20 kodiert. Beides ist nach RFC 3986 gültig, und jeder Server dekodiert beide Formen. Wenn dein Server in der Query nur %20 akzeptiert, liegt der Bug am Server.

Kann ich Credentials (Username/Passwort) in die URL packen?

Ja — setze "username" und "password" im JSON. Sie erscheinen vor dem Host als user:pass@host. RFC 3986 §3.2.1 warnt davor, das in produktiven URLs zu tun, weil sie in Browser-History, Server-Logs und Proxy-Caches landen — okay für einen schnellen Local-Test, nicht okay in geteilten Configs.

Verlässt die URL irgendwann meinen Browser?

Nein. Das JSON-Parsen ist JSON.parse in deinem Tab; das URL-Zusammenbauen ist new URL(...) in deinem Tab; keiner von beiden ruft einen Server. Kein Upload, kein Logging. Du kannst die Seite einmal mit Internet öffnen, dann offline gehen und sie aus dem Cache weiternutzen.

Weitere URL- & JSON-Tools

JSON zu URL ist die eine Hälfte der Hin-und-Rück-Strecke. Hier ist der Rest des Werkzeugkastens: