URL-Encoding kodieren und dekodieren

URL-Encoding im Browser

Dieses Werkzeug kodiert einzelne URL-Bestandteile per Prozentkodierung und dekodiert prozentkodierte Werte wieder zu lesbarem Text. Es ist für Werte gedacht, die in einen Query-Parameter, eine formularnahe Query-Schreibweise oder ein einzelnes Pfadsegment sollen.

Die Eingabe steht im Tool zuerst. Füge den Text oder die Prozentkodierung ein, wähle Modus und Kontext, und prüfe dann die Ausgabe. Die Verarbeitung läuft im Browser; deine Eingaben werden für diese Umwandlung nicht an einen Server gesendet. Das ist ein Datenschutzvorteil, ersetzt aber keine eigene Prüfung, ob sensible Werte überhaupt in URLs, Logs oder Tickets gehören.

Eingabe und Modi

Im Modus Kodieren wird Text in eine URL-taugliche Schreibweise umgewandelt. Umlaute und andere Unicode-Zeichen werden UTF-8-basiert kodiert, zum Beispiel ü als %C3%BC. Reservierte Zeichen wie &, ?, #, / oder = werden geschützt, wenn sie als Daten innerhalb eines URL-Bestandteils gemeint sind. Technisch nutzt das Werkzeug JavaScript-Komponentenkodierung per encodeURIComponent, ohne zusätzliche RFC3986-Nachkodierung von Zeichen wie !, ', (, ) oder *.

Im Modus Dekodieren macht das Werkzeug Prozentkodierung wieder lesbar. Bei ungültigen Prozentsequenzen wie %, %2 oder %GG erscheint eine Fehlermeldung, statt die Eingabe still zu verändern.

Der Kontext ist wichtig. Query-Parameter-Wert passt für einzelne Werte in ?q=... und kodiert Leerzeichen als %20. Formular-/Query-Wert behandelt Leerzeichen wie URLSearchParams bzw. application/x-www-form-urlencoded als +. Pfadsegment ist für genau ein Segment zwischen zwei Slashes gedacht; ein Slash im Eingabetext wird dann als Datenzeichen kodiert.

Ergebnisse und Beispiele

Ein Query-Parameter-Wert wie strom & gas wird im Standardkontext zu strom%20%26%20gas. Das & bleibt dadurch Teil des Suchwerts und trennt nicht versehentlich den nächsten Parameter ab.

In der formularnahen Query-Schreibweise wird derselbe Wert zu strom+%26+gas. Dieser Kontext ist sinnvoll, wenn du bewusst mit Formular- oder URLSearchParams-naher Serialisierung arbeitest. Ein rohes + im Decoder wird dort als Leerzeichen gelesen; ein echtes Pluszeichen muss als %2B vorliegen.

Für ein Pfadsegment wie ordner/name mit leerzeichen lautet die Ausgabe ordner%2Fname%20mit%20leerzeichen. Der kodierte Slash ist hier Absicht: Er steht für ein Datenzeichen im Segment. Wenn du mehrere Pfadsegmente bauen willst, kodiere jedes Segment einzeln und setze die Slashes danach als Strukturzeichen dazwischen.

Wann URL-Encoding passt

URL-Encoding passt, wenn Zeichen innerhalb einer Adresse nicht als URL-Syntax wirken sollen. Das betrifft vor allem einzelne Bestandteile: Query-Werte, Pfadsegmente, Fragmentwerte oder Formularwerte. Für komplette URLs ist das Werkzeug nicht gedacht. Eine ganze Adresse wie https://example.com/?q=strom & gas braucht eine gezielte Behandlung ihrer Bestandteile, keine blinde Kodierung des gesamten Strings.

Wenn du erst entscheiden musst, ob Base64, Base64url, Hex oder URL-Encoding gemeint ist, hilft der Ratgeber Daten kodieren: Base64, Hex und URL. Zurück zur Werkzeugübersicht geht es über den DevToolkit-Tool-Hub.

Unterschied zu Base64, Base64url und Hex

URL-Encoding schützt Zeichen in URL-Bestandteilen. Base64 und das Base64-Werkzeug transportieren Bytes als Text; die URL-sichere Base64-Variante ersetzt dabei Zeichen wie + und /, löst aber nicht automatisch das Problem reservierter URL-Zeichen in normalen Query-Werten. Hexadezimal ist wieder etwas anderes: Es macht Byte- oder Zahlenwerte kompakt lesbar, ist aber kein Ersatz für Prozentkodierung in URLs.

Typische Fehler

Doppelte Kodierung erkennst du oft an Mustern wie %2520. Einmal dekodiert wird daraus %20; der Wert ist dann vermutlich noch nicht vollständig lesbar oder wurde vor dem Speichern schon einmal kodiert.

Ein zweiter Fehler ist der falsche Kontext für +. In normalen Pfadsegmenten und im Standard-Query-Kontext bleibt + ein Pluszeichen. In formularnahen Query-Werten steht ein rohes + dagegen für ein Leerzeichen.

Prüfe außerdem, ob du wirklich einen einzelnen URL-Bestandteil eingibst. Reservierte Zeichen sind nicht generell “verboten”; sie haben nur je nach Position eine Strukturrolle. Genau deshalb ist der Kontext wichtiger als ein pauschales “URL sicher machen”.