Konfig (JSON)

URL

Was ist der URL-Builder?

Übergib ein JSON-Objekt, das die Teile einer URL beschreibt — Protokoll, Host, Pfad, Query-Parameter, Hash — und das Tool gibt dir die zusammengesetzte URL zurück, sauber prozent-kodiert. Unter der Haube nutzt es die native URL-API des Browsers, sodass die Ausgabe exakt dem entspricht, was ein Browser ausgeben würde, wenn du die URL selbst in JavaScript bauen würdest.

Warum es das gibt: URLs von Hand zu bauen ist die Stelle, an der sich Bugs verstecken. Du vergisst ein Leerzeichen im Kundennamen zu kodieren, du kodierst einen schon kodierten Slash doppelt, du verwechselst ? und &, du verlierst einen Wert, weil du + statt %20 verwendet hast. Die WHATWG URL-Spec definiert für jede Eingabe genau eine richtige Antwort, und genau die bekommst du hier. Wiederholte Query-Keys (z. B. tag=red&tag=blue) werden unterstützt, indem du ein Array übergibst — das gleiche Format, das URLSearchParams akzeptiert.

Läuft komplett in deinem Browser. Die JSON-Konfig und die zusammengesetzte URL verlassen deine Maschine nie. Die Encoding-Regeln kommen direkt aus RFC 3986 und den WHATWG-Verfeinerungen darüber. Kombiniere ihn mit dem URL-Parser, wenn du eine URL über ein strukturiertes Formular hin und zurück schicken willst.

So benutzt du den URL-Builder

Drei Schritte. Jeder entspricht einem Button auf dieser Seite.

JSON-Konfig einfügen

Füge links ein JSON-Objekt ein, das die URL-Teile beschreibt. protocol und host sind Pflicht; alles andere ist optional. Klick auf Beispiel, um einen realistischen Fall mit mehreren Query-Parametern und einem 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, hash. In searchParams ist ein String ein Wert; ein Array sind wiederholte Keys.

Lies die zusammengesetzte URL

Im rechten Panel siehst du die zusammengesetzte URL. Leerzeichen werden im Query-String zu +, eckige Klammern zu %5B/%5D, der Pfad wird normalisiert — genau das Encoding, das der URL-Standard definiert. Aktualisiert sich beim Tippen.

Kopieren oder herunterladen

Klick Kopieren, um die URL in die Zwischenablage zu schicken, oder Herunterladen, um sie als Textdatei zu speichern. Mit Leeren im Eingabe-Panel fängst du wieder von vorne an.

Wann du das wirklich brauchst

Test-Fixtures für einen HTTP-Client zusammenbasteln

Du schreibst einen Test, der /v1/orders mit acht Query-Parametern aufruft, zwei davon mit Leerzeichen und einer wiederholt. Die kodierte URL von Hand in den Test zu tippen ist fehleranfällig. Bau sie aus einem JSON-Objekt zusammen, das du aus einem echten Request-Log kopieren kannst, und füge die fertige URL in die Assertion ein. Fertig.

OAuth-Authorize-URLs bauen

OAuth-Authorize-URLs stopfen client_id, redirect_uri, scope, state, response_type und code_challenge in den Query-String. RFC 6749 verlangt genau diese Parameternamen und ein redirect_uri, das schon einmal kodiert ist, bevor die ganze URL nochmal kodiert wird. Der Builder erledigt das transparent — du gibst die Rohwerte rein und er macht das Richtige.

Analytics- oder Share-URLs in einem Skript erzeugen

Wenn du eine Kampagnen-URL mit UTM-Parametern erzeugst, kommen die Werte oft aus einer Tabelle, in der utm_campaign-Werte Leerzeichen, Ampersands und gelegentlich Emojis enthalten. Den URL-Konstruktor das Encoding machen zu lassen ist sicherer als ein String-Template. Die Ausgabe ist identisch mit dem, was Nodes URL-Modul produziert.

Einen Bug aus einem Support-Ticket reproduzieren

Ein Kunde meldet, dass eine Suche mit q=résumé writer in der API einen 500er wirft. Du willst genau diesen Request reproduzieren. Bau die URL aus JSON und schick sie per curl. Der Akzent auf dem e und das Leerzeichen werden so kodiert, wie der Browser sie geschickt hätte — kein Raten.

Häufige Fragen

Was ist der Unterschied zwischen URL-Builder und Strings selbst zusammenkleben?

Encoding. https://api.example.com/orders?customer=Ava Chen ist keine gültige URL — das Leerzeichen zerlegt sie. Der Builder nutzt intern URLSearchParams, das dieses Leerzeichen im Query-String als + und im Pfad als %20 kodiert. Selbstgebaute String-Konkatenation macht früher oder später eines davon falsch.

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

Nutz ein Array als Wert: "tag": ["red", "blue"]. Der Builder gibt tag=red&tag=blue in der angegebenen Reihenfolge aus. Entspricht der URLSearchParams-Spec.

Muss ich den Doppelpunkt nach dem Protokoll (https:) angeben oder reicht https?

Beides funktioniert. Der Builder normalisiert sowohl "protocol": "https" als auch "protocol": "https:" zu https:. Das gleiche gilt für http, ftp, mailto und eigene Schemata.

Kann ich Zugangsdaten (Benutzername/Passwort) in die URL packen?

Ja — setz "username" und "password" in der Konfig. Sie erscheinen vor dem Host als user:pass@host. Beachte: RFC 3986 §3.2.1 warnt bei Produktions-URLs davor, weil sie im Browser-Verlauf, Server-Logs und Proxy-Caches landen.

Warum wird mein Leerzeichen zu + statt %20?

Leerzeichen im Query-Bereich werden typischerweise nach den Regeln von application/x-www-form-urlencoded als + kodiert — das ist, was URLSearchParams ausgibt. Leerzeichen im Pfad werden als %20 kodiert. Beide sind gültig; Server dekodieren beide Formen. Wenn dein Server kaputt ist und nur %20 versteht, hast du ein größeres Problem als dieses Tool.

In welchem Format soll das Eingabe-JSON vorliegen?

Standard-JSON — siehe json.org oder ECMA-404 für die Spec. Keys sind Strings, Werte sind Strings oder (bei searchParams) String-Arrays. Keine Kommentare. Keine nachgestellten Kommas.

Andere URL- & JSON-Tools

Bauen ist eine Richtung. Das passt von Natur aus dazu: