URL

Komponenten

Was ist der URL-Parser?

URL einfügen und das Tool zerlegt sie in die Teile, die dich wirklich interessieren — Protokoll, Host, Port, Pfad, Query-Parameter, Hash. Die Ausgabe ist JSON, also kannst du sie direkt in eine Test-Fixture, ein Debug-Log oder sonstwo hineinkopieren, wo du die Komponenten in strukturierter Form brauchst. Der Parser folgt dem WHATWG URL Standard, den jeder moderne Browser intern verwendet.

Warum ein Parser? Weil eine lange URL mit fünf prozentkodierten Query-Parametern und einem Hash-Fragment zu lesen schmerzhaft ist. Der Browser kann das längst über die URL API, aber du hast keine schnelle Einfügen-und-Sehen-Oberfläche dafür. Das hier ist die. Query-Parameter werden auch dekodiert — %20 wird zu einem Leerzeichen, %5B zu [, wiederholte Schlüssel werden zu einem Array — gleiches Verhalten wie bei URLSearchParams.

Alles läuft in deinem Browser. Kein Upload, kein Server, keine Logs. URL-Parsing ist deterministisch — keine KI, kein Raten, nur derselbe Algorithmus, den RFC 3986 definiert und die WHATWG-Spec verfeinert hat.

So benutzt du den URL-Parser

Drei Schritte. Jeder entspricht einem Button auf dieser Seite.

URL einfügen oder Beispiel laden

Wirf eine URL ins linke Panel. Klick auf Beispiel, um einen realistischen Fall mit Prozent-Encoding, wiederholten Query-Schlüsseln und Hash-Fragment zu laden. Beispiel-URL:

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

Alles, was der URL-Konstruktor akzeptiert, geht — inklusive <code>file://</code>, <code>mailto:</code>, eigene Schemata, IPv6-Hosts und Userinfo (<code>user:pass@host</code>).

Komponenten lesen

Das rechte Panel zeigt die geparste URL als JSON: protocol, host, port, pathname, pathSegments (der Pfad in ein Array zerlegt), searchParams (dekodierte Schlüssel-Wert-Paare, mit Arrays für wiederholte Schlüssel) und hash. Aktualisiert sich beim Tippen.

Kopieren oder Herunterladen

Klick auf Kopieren, um das JSON in die Zwischenablage zu schicken, oder Herunterladen, um es als .json-Datei zu speichern. Minifizieren drückt das JSON auf eine Zeile zusammen, falls du es für eine Log-Zeile brauchst. Nutze Leeren im Eingabe-Panel, um neu anzufangen.

Wann du das wirklich brauchst

Redirects und Analytics-URLs debuggen

Eine URL mit zwölf Query-Parametern aus einem Anzeigen-Tracking-Redirect ist in der Adresszeile unlesbar. Hier einfügen und du siehst die Parameter zeilenweise dekodiert, mit dem Ziel-url-Parameter komplett ausgepackt. Passt gut zu unserem URL Cleaner (sobald er da ist), der Tracker entfernt.

Webhook- und OAuth-Callback-URLs inspizieren

OAuth-Callbacks und Webhook-Payloads stopfen Status in den Query-String. Ihn aufzudröseln macht offensichtlich, ob das state-Token fehlt, der code abgeschnitten wurde oder die redirect_uri doppelt kodiert ist. RFC 6749 verlangt diese Parameter und das Tool legt sie alle auf einmal offen.

Test-Fixtures bauen

Wenn du Tests gegen eine URL schreibst, willst du sie meistens als strukturiertes Objekt, nicht als String. URL einfügen, JSON kopieren, in deine Fixture-Datei werfen. Spart dir, protocol: 'https:' heute zum fünften Mal von Hand zu tippen.

Sanity-Check für Support-Tickets

"Es ist kaputtgegangen, als ich diesen Link geklickt habe" — der Link ist 400 Zeichen lang mit doppelt kodierten Slashes. Der Parser zeigt dir genau das, was der Browser sehen würde, inklusive ob %252F ein literales %2F bedeutet oder ein Pfadtrenner ist, der auf dem Weg durch einen Proxy doppelt kodiert wurde.

Häufige Fragen

Funktioniert das mit relativen URLs?

Nein — der URL-Konstruktor braucht eine absolute URL (mit Protokoll wie https:// oder file://). Für relative URLs setze erst eine Basis wie https://example.com davor und entferne sie aus dem Ergebnis. Die WHATWG-Spec beschreibt die Zwei-Argumente-Form (new URL(relative, base)), die Browser intern nutzen.

Wie geht das Tool mit wiederholten Query-Schlüsseln um?

Wiederholte Schlüssel werden zu einem Array zusammengefasst. ?tag=red&tag=blue wird also in der Ausgabe zu "tag": ["red", "blue"]. Das passt zu der Art, wie die meisten Server-Frameworks (Express, FastAPI, ASP.NET) Query-Strings parsen.

Und was ist mit Array-Klammer-Notation wie ?items[]=1&items[]=2?

Der Parser behandelt die Klammern als Teil des Schlüssels — du siehst also "items[]": ["1", "2"]. Das ist ehrlich gegenüber den Bytes auf der Leitung. Wenn du einen framework-spezifischen Decoder brauchst (PHP, Rails, qs.js), mach die Nachverarbeitung auf der geparsten Ausgabe.

Ist es sicher, Credentials in URLs (user:pass@host) hier einzufügen?

Das Parsen passiert komplett in deinem Browser — die URL verlässt deine Maschine nie. Allerdings ist das Einbetten von Credentials in eine URL generell unerwünscht (RFC 3986 §3.2.1 nennt die Sicherheitsrisiken), und die meisten Browser entfernen sie stillschweigend. Wenn du eine einfügst, tauchen die Felder username und password in der Ausgabe auf.

Kann es internationalisierte Domainnamen (IDNs) verarbeiten?

Der URL-Konstruktor des Browsers kann IDN-Domains, aber die Ausgabe zeigt eventuell die Punycode-Form (xn--...) statt der Unicode-Form. So würde die URL tatsächlich über die Leitung gehen. Wenn du zwischen beiden konvertieren musst, kommt bald ein dediziertes Punycode-Tool in diese Sektion.

Warum heißt die Ausgabe "Komponenten" und nicht "JSON"?

Es ist JSON — aber die Einrahmung zählt. Die Ausgabe sind die Teile der URL, strukturiert. Wenn du die Seite als "URL → JSON-Konverter" betrachtest, verfehlst du den Punkt: der Wert liegt in der Aufschlüsselung, nicht im Format.

Andere URL- und JSON-Tools

Parsen ist eine Operation. Hier ist, was natürlich dazu passt: