URL-Encoding verstehen: Was hinter den Prozentzeichen in Webadressen steckt

Das Internet wurde in den USA erfunden. Klingt banal, hat aber weitreichende Konsequenzen – vor allem für alle, die nicht ausschließlich mit den 26 Buchstaben des englischen Alphabets arbeiten. Als Tim Berners-Lee Anfang der 1990er-Jahre die Grundlagen des World Wide Web definierte, legte er auch fest, welche Zeichen in einer URL vorkommen dürfen. Und diese Liste ist erstaunlich kurz.

Erlaubt sind im Wesentlichen lateinische Buchstaben ohne Akzente, Ziffern und eine Handvoll Sonderzeichen wie Bindestrich, Punkt oder Unterstrich. Alles andere – Umlaute, Leerzeichen, Fragezeichen außerhalb ihrer Sonderfunktion, kyrillische Buchstaben, chinesische Schriftzeichen – muss codiert werden. Das Verfahren dahinter nennt sich Percent-Encoding, im deutschsprachigen Raum häufiger als URL-Encoding bezeichnet.

Die Idee ist simpel: Jedes Zeichen, das nicht zum erlaubten Zeichensatz gehört, wird durch ein Prozentzeichen gefolgt von seinem hexadezimalen Wert ersetzt. Aus einem Leerzeichen wird %20, aus einem Ausrufezeichen %21. Bei Mehrbyte-Zeichen wie dem deutschen ü entstehen gleich mehrere solcher Blöcke – daher sieht „München" in codierter Form auch so unhandlich aus.

Mal ehrlich: Als Nutzer muss man davon eigentlich nichts mitbekommen. Moderne Browser zeigen in der Adressleiste die lesbaren Zeichen an, auch wenn im Hintergrund längst die codierte Variante verwendet wird. Für Entwickler sieht die Sache allerdings anders aus. Wer APIs ansteuert, Formulardaten verarbeitet oder Links dynamisch zusammenbaut, muss genau verstehen, wann und wie codiert wird.

URL-Encoding basiert auf einem klar definierten Standard, festgehalten in RFC 3986. Das Prinzip lässt sich in wenigen Sätzen zusammenfassen: Nimm das Zeichen, wandle es in seine UTF-8-Byte-Repräsentation um und schreibe jeden Byte-Wert als Prozentzeichen plus zwei Hex-Ziffern. Klingt kompliziert? Ist es aber nicht, wenn man es einmal durchspielt.

Nehmen wir das Zeichen „ä". In UTF-8 wird es durch zwei Bytes dargestellt: 0xC3 und 0xA4. Codiert ergibt das %C3%A4. Das „ß" wird zu %C3%9F, ein einfaches Leerzeichen zu %20. Manche Zeichen haben auch historische Sonderformen – das Plus-Zeichen (+) steht in manchen Kontexten ebenfalls für ein Leerzeichen, was immer wieder für Verwirrung sorgt. Dazu gleich mehr.

Wichtig zu verstehen: Nicht jedes Sonderzeichen muss codiert werden. Die sogenannten reservierten Zeichen wie Schrägstrich (/), Fragezeichen (?) oder Ampersand (&) haben in URLs eine strukturelle Bedeutung. Sie trennen Pfadbestandteile, leiten Querystrings ein oder separieren Parameter. Wenn diese Zeichen als Teil eines Wertes und nicht als Strukturelement auftreten sollen, müssen auch sie codiert werden. Genau hier passieren in der Praxis die meisten Fehler.

Dann gibt es noch die unreservierten Zeichen: Buchstaben (A-Z, a-z), Ziffern (0-9) sowie Bindestrich, Punkt, Unterstrich und Tilde. Die dürfen unverändert in einer URL stehen. Alles, was nicht in diese beiden Kategorien fällt, muss zwingend durch seine Prozent-Entsprechung ersetzt werden. Das betrifft eben auch alle Nicht-ASCII-Zeichen – also praktisch jedes Schriftsystem jenseits des englischen Grundalphabets.

Kennen Sie das? Sie bauen einen Link zusammen, der einen Suchbegriff mit Leerzeichen enthält, und fragen sich: %20 oder +? Beides sieht man ständig in URLs, und beides steht für ein Leerzeichen. Aber der Kontext macht den Unterschied, und genau hier schleichen sich hartnäckige Bugs ein.

Die Kurzfassung: In der Pfadkomponente einer URL ist %20 die korrekte Codierung für ein Leerzeichen. Im Querystring – also nach dem Fragezeichen – akzeptieren viele Server auch das Plus-Zeichen als Alternative. Diese Konvention stammt aus dem alten HTML-Standard für Formulardaten (application/x-www-form-urlencoded). Browser ersetzen Leerzeichen in Formularfeldern durch +, nicht durch %20, wenn das Formular abgeschickt wird.

Und jetzt wird es tückisch: Was passiert, wenn jemand tatsächlich ein Plus-Zeichen eingeben will? Richtig – dann muss das Plus selbst codiert werden, nämlich als %2B. Wer hier nicht sauber unterscheidet, hat schnell Daten, die falsch ankommen. Ich habe selbst schon Stunden damit verbracht, einen Bug zu suchen, der sich als falsch codiertes Plus entpuppte. Keine schöne Erfahrung.

Mein Tipp aus der Praxis: Verwenden Sie im Zweifelsfall immer %20 und codieren Sie konsequent alles, was nicht eindeutig unreserviert ist. Die meisten Programmiersprachen bieten dafür eigene Funktionen an – encodeURIComponent() in JavaScript etwa macht genau das Richtige. Aber Vorsicht: encodeURI() codiert bewusst weniger, weil es davon ausgeht, dass die Struktur der URL erhalten bleiben soll. Die falsche Funktion am falschen Ort, und schon stimmt wieder nichts.

Gerade bei der Arbeit mit externen APIs lohnt es sich, die Dokumentation genau zu lesen. Manche Schnittstellen erwarten Leerzeichen als +, andere bestehen auf %20. Einheitlichkeit wäre schön, aber das Web ist gewachsen, nicht designt.

In meiner Erfahrung als Entwickler und Redakteur begegne ich immer wieder denselben Stolperfallen. Die häufigste: doppeltes Encoding. Das passiert, wenn ein bereits codierter String noch einmal durch eine Encoding-Funktion geschickt wird. Aus %20 wird dann %2520, weil das Prozentzeichen selbst nochmal codiert wird. Der Server empfängt am Ende nicht das erwartete Leerzeichen, sondern den String „%20" als Klartext. Klassiker.

Ein weiterer Dauerbrenner: Pfadtrenner werden versehentlich mitcodiert. Wer eine komplette URL an encodeURIComponent() übergibt, bekommt eine unbrauchbare Zeichenkette zurück, weil auch die Schrägstriche, das Protokoll und alles andere codiert wird. Stattdessen sollte man immer nur die variablen Bestandteile codieren – also den Dateinamen, den Parameterwert, aber nicht die Struktur drumherum.

Dann gibt es noch das Thema Zeichensatz-Verwirrung. URL-Encoding setzt voraus, dass der Eingabetext als UTF-8 vorliegt. Wenn die Quelle aber in ISO-8859-1 oder einem anderen Encoding daherkommt, entstehen falsche Byte-Werte und damit falsche Prozent-Codes. Das Ergebnis: Auf der Gegenseite erscheinen Fragezeichen oder kryptische Symbole statt der gewünschten Zeichen. Gerade bei älteren Systemen, die noch mit Latin-1 arbeiten, ist das ein reales Problem.

Weniger offensichtlich, aber genauso ärgerlich: Vergessenes Decoding. Daten kommen codiert an, werden in eine Datenbank geschrieben und bei der Ausgabe nicht decodiert. Der Nutzer sieht dann „Sch%C3%B6ne%20Gr%C3%BC%C3%9Fe" statt „Schöne Grüße". Oder schlimmer: Die Daten werden beim nächsten Speichern erneut codiert, und der Salat wird immer größer. Hier hilft nur Disziplin – codieren bei der Ausgabe in die URL, decodieren beim Einlesen, und dazwischen mit den echten Zeichen arbeiten.

Jede gängige Programmiersprache bringt eigene Funktionen für die Prozent-Codierung mit, aber sie verhalten sich nicht alle gleich. Wer zwischen verschiedenen Sprachen wechselt oder ein Frontend mit einem Backend in einer anderen Sprache verbindet, sollte die Unterschiede kennen.

In JavaScript stehen encodeURI() und encodeURIComponent() zur Verfügung. Erstere codiert nur das Nötigste und lässt reservierte Zeichen wie /, ? und # in Ruhe. Die zweite Variante codiert alles außer den unreservierten Zeichen und ist die richtige Wahl für einzelne Parameterwerte. Zum Decodieren gibt es die entsprechenden Gegenstücke decodeURI() und decodeURIComponent(). Klingt logisch, trotzdem schnappt die Falle regelmäßig zu.

Python nutzt das Modul urllib.parse mit den Funktionen quote() und quote_plus(). Letztere ersetzt Leerzeichen durch + statt %20 – gedacht für Formulardaten im Querystring. In Python 2 war das alles etwas chaotischer, aber wer 2026 noch Python 2 einsetzt, hat andere Probleme. Zum Decodieren gibt es unquote() und unquote_plus().

In PHP heißen die Funktionen urlencode() und rawurlencode(). Der Unterschied: urlencode() ersetzt Leerzeichen durch +, rawurlencode() durch %20. Für Pfadbestandteile also rawurlencode(), für Querystring-Parameter kann man beides verwenden. Auch hier gilt: Die falsche Funktion am falschen Ort kostet Zeit.

Java bietet URLEncoder.encode(), das aber eine veraltete Konvention verwendet und Leerzeichen als + codiert. Für RFC-konformes Encoding muss man oft selbst Hand anlegen oder Bibliotheken wie Apache Commons oder die eingebaute URI-Klasse verwenden. Nicht gerade elegant, aber machbar.

Mein Rat: Testen Sie die Encoding-Funktion Ihrer Wahl einmal bewusst mit Sonderzeichen, Umlauten, Emojis und dem Plus-Zeichen. Dann wissen Sie sofort, wie sie sich verhält, und ersparen sich spätere Überraschungen.

URL-Encoding betrifft nicht nur den Pfad und die Parameter, sondern wirft auch bei Domainnamen Fragen auf. Wer schon einmal versucht hat, eine Domain mit Umlauten zu registrieren – etwa „bücher.de" –, ist auf das Thema Punycode gestoßen. Das ist gewissermaßen das Pendant zum Percent-Encoding, allerdings für den Hostnamen-Teil der URL.

Der Grund: Das Domain Name System (DNS) arbeitet intern nur mit ASCII-Zeichen. Internationalisierte Domainnamen (IDN) werden deshalb in eine ASCII-kompatible Darstellung umgewandelt. Aus „bücher.de" wird „xn--bcher-kva.de". Das passiert automatisch im Browser, aber wer programmatisch mit solchen Domains arbeitet, muss die Konvertierung selbst vornehmen.

Im Pfadteil einer URL hingegen greift normales Percent-Encoding. Ein Link wie „https://beispiel.de/über-uns" wird intern zu „https://beispiel.de/%C3%BCber-uns". Moderne Browser sind smart genug, dem Nutzer trotzdem die lesbare Variante anzuzeigen. Aber Vorsicht: Nicht jedes Tool und nicht jede Bibliothek geht damit gleich um.

Spannend wird es bei Emojis in URLs. Ja, das funktioniert tatsächlich. Ein Herz-Emoji (❤) wird in UTF-8 zu drei Bytes und damit zu %E2%9D%A4. Ob das sinnvoll ist, steht auf einem anderen Blatt – aber technisch möglich ist es. Manche Marketing-Abteilungen finden das kreativ, ich persönlich halte es für eine fragwürdige Idee, weil solche Links schwer zu kommunizieren sind und in manchen Systemen Probleme verursachen.

Was viele nicht wissen: Auch der Fragment-Identifier – also alles nach dem #-Zeichen – wird nicht an den Server übermittelt. Er bleibt komplett im Browser. Trotzdem gelten dort dieselben Encoding-Regeln, weil der Browser den Fragment-Teil parsen und verarbeiten muss. In Single-Page-Applications, die das Fragment für clientseitiges Routing verwenden, ist sauberes Encoding also genauso relevant wie im restlichen Teil der Adresse.

Seien wir ehrlich: Niemand möchte Prozent-Codes von Hand berechnen. Und das muss auch niemand. Es gibt hervorragende Online-Tools, die das zuverlässig erledigen, und für die tägliche Arbeit sind sie Gold wert. Gerade wenn man schnell prüfen will, ob ein bestimmter String korrekt codiert ist, spart ein URL-Encoder/Decoder eine Menge Zeit.

Direkt hier auf der Seite können Sie unseren URL Encoder Decoder verwenden. Einfach den Text eingeben, auf Codieren klicken, fertig. Das Tool arbeitet mit UTF-8 und liefert RFC-konforme Ergebnisse. Zum Decodieren funktioniert es genauso – codierten String einfügen, decodieren lassen und das Ergebnis in Klartext lesen.

Wer häufig mit codierten Daten arbeitet, wird auch den Base64 Konverter zu schätzen wissen. Base64 und URL-Encoding werden gerne verwechselt, weil beides nach „irgendwie codiert" aussieht. Aber die Verfahren haben unterschiedliche Zwecke: URL-Encoding macht einzelne Zeichen URL-sicher, Base64 wandelt beliebige Binärdaten in einen ASCII-String um. Manchmal braucht man sogar beides – etwa wenn ein Base64-String in eine URL eingebettet werden soll, weil Base64 die Zeichen + und / verwendet, die in URLs reserviert sind.

Und wenn Sie gerade dabei sind, API-Responses zu debuggen: Unser JSON Formatter hilft dabei, verschachtelte Datenstrukturen lesbarer zu machen. Gerade wenn URL-codierte Werte in JSON-Antworten stecken, wird es schnell unübersichtlich, und ein gutes Formatierungswerkzeug spart Nerven.

Für die Integration in den eigenen Workflow empfehle ich außerdem, die Entwicklertools im Browser zu nutzen. In der Konsole können Sie jederzeit encodeURIComponent() und decodeURIComponent() aufrufen – schneller geht es kaum. Manche Entwickler haben sich dafür auch Snippets oder Bookmarklets eingerichtet. Wie auch immer man es löst: Das manuelle Nachschlagen von Hex-Werten gehört wirklich der Vergangenheit an.

URL-Encoding ist eines dieser Themen, die unscheinbar wirken, aber bei Fehlern für richtig hartnäckige Bugs sorgen können. Wer das Prinzip einmal verstanden hat – unreservierte Zeichen bleiben, alles andere wird in Prozent-Hex-Notation umgewandelt –, hat das Schlimmste schon hinter sich. Achten Sie auf den Unterschied zwischen Pfad und Querystring, vermeiden Sie doppeltes Encoding und nutzen Sie die richtigen Funktionen Ihrer Programmiersprache. Und wenn es mal schnell gehen soll, nehmen Sie einfach ein gutes Online-Tool – das spart Zeit und schützt vor Flüchtigkeitsfehlern.