URL Encoder & Decoder

Was dieses Tool macht

URLs dürfen nur einen begrenzten Satz an ASCII-Zeichen enthalten. Alles andere – Leerzeichen, chinesische Zeichen, &, =, ?, # und die meisten Satzzeichen – muss als %XX-Bytes prozentkodiert werden, bevor es sicher in einem Link, einer Formularübermittlung oder einem API-Aufruf reisen kann. Diese Seite übernimmt diese Kodierung in beide Richtungen und schlüsselt – anders als die meisten Encoder – das Ergebnis zusätzlich auf: Fügen Sie eine beliebige URL oder einen Query-String ein, und die Parameter erscheinen als dekodierte Schlüssel-Wert-Tabelle, sodass Sie einen Tracking-Link oder eine OAuth-Weiterleitung auf einen Blick lesen können.

Text wird als UTF-8 behandelt, sodass aus 中文 genau %E4%B8%AD%E6%96%87 wird, wie Browser und Server es erwarten. Das Dekodieren ist tolerant: Ein einzelnes %, das kein gültiges Escape ist, bleibt unverändert, statt einen Fehler auszulösen, und + wird als Leerzeichen behandelt, wenn Sie Formulardaten dekodieren.

Komponente vs. ganze URL kodieren

Komponente kodieren ist JavaScripts encodeURIComponent: Es maskiert alles außer Buchstaben, Ziffern und -_.!~*'(). Verwenden Sie es für einen einzelnen Wert, der in einen Query-Parameter, ein Pfadsegment oder ein Formularfeld kommt. URL kodieren ist encodeURI: Es lässt die Strukturzeichen :/?#[]@!$&'()*+,;= unangetastet, damit eine vollständige Adresse eine gültige Adresse bleibt, und maskiert nur Leerzeichen und Nicht-ASCII-Text. Das falsche zu verwenden ist der klassische Fehler – encodeURIComponent auf eine komplette URL verwandelt jedes / in %2F und zerstört den Link, während encodeURI auf einen Wert mit & ihn stillschweigend in zwei Parameter aufspaltet.

Die Option Leerzeichen als + wechselt zwischen %20 (RFC 3986, in URLs verwendet) und + (application/x-www-form-urlencoded, in HTML-Formular-Bodies und vielen älteren Query-Strings). Beide werden hier korrekt dekodiert; wählen Sie die Kodierung, die Ihr Ziel erwartet.

Häufige Fehler

Doppelte Kodierung: Wird ein bereits kodierter Wert erneut kodiert, wird aus %20 ein %2520, und der Server sieht ein wörtliches %20. Enthält Ihre dekodierte Ausgabe noch %XX-Sequenzen, dekodieren Sie noch einmal. Vergisst man, & oder # innerhalb eines Werts zu kodieren, wird der Parameter abgeschnitten. Die ganze URL mit encodeURIComponent zu kodieren zerstört Schema und Schrägstriche. Das Vermischen der Konventionen + und %20 zwischen Client und Server erzeugt Pluszeichen in Benutzernamen. Und schließlich: Prozentkodierung ist weder Verschlüsselung noch Verschleierung – ein Wert ist nach dem Dekodieren vollständig lesbar, verlassen Sie sich also nie darauf, um Tokens zu verbergen; brauchen Sie Undurchsichtigkeit für eine Payload, ist Base64 die übliche Transportkodierung, und auch sie ist trivial umkehrbar.

Hintergrund: Woher die Prozentkodierung stammt

Die Prozentkodierung wurde mit der ersten URL-Spezifikation definiert, RFC 1738 (1994), verfasst von Tim Berners-Lee und Kollegen, und in RFC 3986 (2005) verfeinert, dem aktuellen Standard für die URI-Syntax. Der %-Escape-Mechanismus ist älter als die Vorherrschaft von UTF-8, weshalb ältere Systeme Bytes manchmal in Latin-1 oder Shift-JIS kodieren und beim Dekodieren als UTF-8 Zeichensalat (Mojibake) erzeugen – der HTML5-URL-Standard (WHATWG) schrieb schließlich UTF-8 für neue Kodierungen vor. Die Konvention + für Leerzeichen stammt aus der separaten HTML-Formular-Spezifikation, nicht aus dem URL-Standard – der historische Grund, warum heute zwei Leerzeichen-Kodierungen nebeneinander existieren.

Wo es verwendet wird

API-Anfragen von Hand bauen (Suchbegriffe, Filter, Callback-URLs), Tracking-Links von Werbeplattformen debuggen (utm_source, gclid, fbclid), OAuth- und SSO-Weiterleitungen lesen (redirect_uri, state, scope), mailto:- und tel:-Links mit Betreffzeilen und Texten erstellen, Links mit chinesischen oder japanischen Pfaden teilen und Webhook-Payloads prüfen, die als Formulardaten gesendet werden. Die Parametertabelle ist praktisch, um eine lange URL aus einem Support-Ticket einzufügen und genau zu sehen, was angefragt wurde. Werte in einem Query-String sind oft JSON oder Base64 – dekodieren Sie hier zuerst und fügen Sie den Wert dann in das passende Tool ein.

Häufig gestellte Fragen