Schon mal einen Link eingefügt und %C3%A4 gesehen, wo ein Buchstabe stehen sollte, oder einen Query-Parameter, der plötzlich kaputt war? Das ist URL-Kodierung am Werk. Sobald du sie verstehst, werden aus diesen kryptischen Strings lesbare, nachvollziehbare Angaben.
Eine Eingabe, drei Lektionen. Wir haben
台北 101 & friends?mit unserem URL-Encoder kodiert und erhielten:%E5%8F%B0%E5%8C%97%20101%20%26%20friends%3FDrei Dinge lassen sich daran ablesen. Jedes chinesische Zeichen wurde zu drei Bytes (
%E5%8F%B0), denn UTF-8 braucht für CJK drei. Die Leerzeichen wurden%20, nicht+— die Plus-Form gehört in Formularinhalte, nicht in Pfade. Und&sowie?wurden genau deshalb maskiert, weil sie unmaskiert den Wert beenden und einen neuen Parameter beginnen würden. Füge denselben Text ein und vergleiche.
Was ist URL-Kodierung?
URL-Kodierung — auch Prozentkodierung (percent-encoding) genannt — stellt Zeichen dar, die in einer URL nicht erlaubt sind oder sonst falsch gelesen würden. Jedes solche Zeichen wird durch ein % gefolgt vom zweistelligen Hexadezimalwert seines Bytes ersetzt. Ein Leerzeichen wird zu %20, ein & zu %26, und das ä (in UTF-8) zu zwei Bytes, %C3%A4.
Die Regeln stammen aus dem URL-Standard RFC 3986. Das Ziel ist einfach: Eine URL soll das Kopieren, Versenden per E-Mail und das Parsen durch jeden Server ohne Mehrdeutigkeit überstehen.
Mit einem URL-Encoder / -Decoder kodierst oder dekodierst du jeden String sofort — er läuft lokal in deinem Browser.
Warum URLs Kodierung brauchen
Eine URL darf nur einen begrenzten Satz an ASCII-Zeichen enthalten. Alles andere — Leerzeichen, Umlaute, Nicht-ASCII-Schriften oder Zeichen mit besonderer Bedeutung wie ?, &, #, / — muss prozentkodiert werden, damit es nicht als URL-Struktur missverstanden wird.
Nimm ? als Beispiel: In einer URL markiert es den Beginn des Query-Strings. Willst du ein wörtliches Fragezeichen innerhalb eines Werts, musst du %3F schreiben, sonst behandelt der Parser alles danach als Parameter. Kodierung beseitigt diese Mehrdeutigkeit.
Wie gängige Zeichen kodiert werden
Hier die Zeichen, über die man am häufigsten stolpert, mit ihrer prozentkodierten Form:
| Zeichen | Kodiert | Hinweis |
|---|---|---|
| Leerzeichen | %20 | + nur in Formulardaten (siehe unten) |
& | %26 | trennt Query-Parameter |
? | %3F | beginnt den Query-String |
= | %3D | trennt Schlüssel und Wert |
# | %23 | beginnt das Fragment |
/ | %2F | Pfadtrenner |
+ | %2B | wörtliches Plus, damit es nicht als Leerzeichen gilt |
ä | %C3%A4 | Nicht-ASCII, zwei UTF-8-Bytes |
Nicht-ASCII-Text (Umlaute, chinesische oder japanische Zeichen, Emojis) wird zuerst in seine UTF-8-Bytes umgewandelt, dann wird jedes Byte prozentkodiert. Deshalb kann ein einziges sichtbares Zeichen zu mehreren %XX-Gruppen werden.
Hier eine Zeichenkette durch unseren eigenen URL-Encoder: 台北 101 & friends? wird %E5%8F%B0%E5%8C%97%20101%20%26%20friends%3F. Drei Fakten lassen sich daran ablesen — jedes chinesische Zeichen belegte drei Bytes, die Leerzeichen wurden %20 und nicht +, und & sowie ? wurden maskiert, weil sie unmaskiert den Wert beenden und einen neuen Parameter beginnen würden.
Statt die RFC-Tabelle zu wiederholen, hier die Ausgabe unseres URL-Encoders für acht Eingaben, die jede Kategorie mindestens einmal treffen. Zwei kommen unverändert zurück, und das ist der interessante Teil: ~, _, . und - sind unreserved, ein korrekter Encoder muss sie in Ruhe lassen.
| Eingabe | Kodiert |
|---|---|
hello | hello |
hello world | hello%20world |
a+b=c | a%2Bb%3Dc |
100% | 100%25 |
台北 | %E5%8F%B0%E5%8C%97 |
?q=x&r=y | %3Fq%3Dx%26r%3Dy |
a/b | a%2Fb |
~_.- | ~_.- |
Reservierte vs. nicht reservierte Zeichen
- Nicht reservierte Zeichen (
A–Z a–z 0–9 - _ . ~) müssen nie kodiert werden. - Reservierte Zeichen (
: / ? # [ ] @ ! $ & ' ( ) * + , ; =) haben strukturelle Bedeutung in einer URL. Ob du sie kodierst, hängt vom Kontext ab — innerhalb eines Werts müssen sie kodiert werden, als Struktur nicht.
Genau das ist der Kern der Entscheidung zwischen encodeURIComponent und encodeURI weiter unten.
Wann muss man kodieren?
Die kurze Antwort: Kodiere die Teile, die du in eine URL einsetzt, nicht die fertig gebaute URL.
- Kodiere einen Wert, den du einfügst — einen Suchbegriff, einen Dateinamen, ein Weiterleitungsziel, alles aus Benutzereingaben oder einem anderen System.
- Kodiere nicht blind eine ganze, fertige URL — das würde die
/ ? & =escapen, die sie zusammenhalten, und den Link zerstören.
Ein hilfreiches Denkmodell: Bau die URL-Struktur selbst und kodiere jedes Stück, bevor du es einsetzt. Kodierst du den Parameterwert rot & blau, ergibt das rot%20%26%20blau, was sicher in ?farbe=rot%20%26%20blau passt.
encodeURIComponent vs. encodeURI
encodeURIComponentkodiert auch reservierte Zeichen. Nutze es für einen einzelnen Wert — einen Query-Parameter, ein Pfadsegment.encodeURIlässt strukturelle Zeichen (/ ? & =) unverändert. Nutze es für eine ganze URL, die du nicht zerteilen willst.
encodeURIComponent("a b&c=d") // "a%20b%26c%3Dd" ✅ sicher als Wert
encodeURI("https://x.com/a b") // "https://x.com/a%20b" ✅ ganze URLDie falsche Wahl ist eine häufige Bug-Quelle: Nutzt du encodeURI auf einem Wert, wird das & darin nicht escaped und zerstört deinen Query-String.
Leerzeichen in einer URL kodieren: %20 vs. +
Leerzeichen bringen mehr Leute durcheinander als jedes andere Zeichen. Sowohl %20 als auch + können ein Leerzeichen darstellen, aber in verschiedenen Kontexten:
- Im URL-Pfad und in modernen Query-Strings ist der Standard
%20. - Das
+für ein Leerzeichen stammt aus dem älterenapplication/x-www-form-urlencoded-Format von HTML-Formularen. Dort muss ein wörtliches+als%2Bgeschrieben werden.
Im Zweifel ist %20 die sichere, universelle Wahl — und genau das erzeugt unser Tool. Ein Leerzeichen in einer URL sollte also fast immer als %20 erscheinen, nie als echtes Leerzeichen.
Zum Vergleich derselbe Text durch unser Base64-Werkzeug: 5Y+w5YyXIDEwMQ==. Beide starten bei denselben UTF-8-Bytes und laufen dann völlig auseinander: Base64 drückt jedes Byte in einem 64-Zeichen-Alphabet aus und füllt auf ein Vielfaches von vier auf, Prozentkodierung lässt sichere Zeichen sichtbar und maskiert nur den Rest.
Hier beginnt auch die +-Verwirrung. Unser Encoder gibt für a+b=c a%2Bb%3Dc zurück — das Plus selbst wird zu %2B. Es muss. Bliebe ein wörtliches + stehen, würde jeder Decoder, der + als Leerzeichen liest, den Wert stillschweigend zerstören — und Formular-Decoder tun genau das. + als Leerzeichen und + als Plus können unkodiert nie koexistieren; der Encoder löst das, indem er nie ein nacktes + ausgibt.
Der klassische Doppelkodierungs-Bug
Wird ein String zweimal kodiert, wird %20 zu %2520 (weil das % selbst zu %25 kodiert wird). Symptome: buchstäbliches %20 im Browser oder Leerzeichen, die zu %2520 werden. Die Lösung: genau einmal kodieren — bei unklarem Zustand zuerst dekodieren. Ein Decoder macht es leicht zu prüfen, was du tatsächlich hast.
Derselbe Mechanismus erklärt die Doppelkodierung. % ist in einer URL ebenfalls nicht sicher — unser Encoder macht aus 100% 100%25. Schickt man diese Ausgabe ein zweites Mal durch, wird %25 zu %2525: weiterhin eine gültige URL, weiterhin dekodierbar, nur dekodiert sie zur falschen Zeichenkette. Doppelkodierung ist niemals ein Syntaxfehler — deshalb überlebt sie bis in die Produktion.
Wie man eine URL online kodiert und dekodiert
Du musst dir keine Hex-Tabellen merken. Füge deinen Text oder deine URL in den Online-URL-Encoder / -Decoder ein, wechsle zwischen Kodieren und Dekodieren und kopiere das Ergebnis. Er arbeitet vollständig im Browser, es wird also nichts hochgeladen — praktisch bei Links mit Tokens oder persönlichen Daten. Für Binärdaten oder Header brauchst du stattdessen Base64; der Leitfaden Base64 vs. URL-Kodierung erklärt, wann welches Verfahren passt.
Häufige Fragen
Muss ich eine normal aussehende URL vor dem Teilen kodieren? Meist nicht — wenn sie im Browser schon funktioniert, ist sie in Ordnung. Kodiere nur die Werte, die du in eine neue URL einbaust.
Warum hat mein & den Link in zwei Teile gespalten? Ein nicht kodiertes & startet einen neuen Query-Parameter. Innerhalb eines Werts muss es %26 sein.
Warum steht %2520 in meinem Link? Das ist ein doppelt kodiertes Leerzeichen. Einmal dekodieren stellt das ursprüngliche %20 wieder her.
Sind %20 und + austauschbar? Nur in x-www-form-urlencoded-Formulardaten. Im Pfad und in allgemeinen Query-Strings ist %20 vorzuziehen.
Kurzreferenz
- Einen Parameterwert kodieren? →
encodeURIComponent. - Eine ganze URL kodieren? →
encodeURI. - Ein Leerzeichen? →
%20(nur in Formulardaten+). - Ein verirrtes
%XX? → dekodieren, um das Original zu lesen.
Kodiere und dekodiere URLs und Query-Parameter sofort mit dem kostenlosen URL-Encoder / -Decoder — er läuft lokal in deinem Browser.