BrowserTools
Startseite / Encoder / URL kodieren / dekodieren

URL kodieren / dekodieren

Kodiere oder dekodiere URLs und Abfrageparameter per Prozent, komponentensicherer Modus und Voll-URI-Modus.

Betreut von BrowserTools · Zuletzt aktualisiert 2026-06-06

URL kodieren / dekodieren wird geladen… Wenn nichts passiert, aktiviere JavaScript.

Die Prozentkodierung, gemeinhin URL-Kodierung genannt, ist der in RFC 3986 definierte Mechanismus, um beliebige Zeichen sicher innerhalb eines Uniform Resource Identifier darzustellen. Das Adressierungssystem des Internets wurde um ASCII herum entworfen, sodass jedes Zeichen außerhalb einer kleinen sicheren Menge (Leerzeichen, akzentuierte Buchstaben, Satzzeichen, Emoji oder rohe Binärdaten) durch ein Prozentzeichen ersetzt werden muss, gefolgt von zwei Hexadezimalziffern, die den Bytewert des Zeichens in UTF-8 darstellen. Das Schema ist Teil des Webs, seit Tim Berners-Lee 1990 am CERN die URLs definierte, und wurde in RFC 1738 formell standardisiert, später 2005 durch RFC 3986 abgelöst.

Beispiele

Eingabe hello world & co=1
Ausgabe hello%20world%20%26%20co%3D1

Prozentkodierung (encodeURIComponent): Das Leerzeichen wird zu %20.

Eingabe hello world & co=1
Ausgabe hello+world+%26+co%3D1

Formularkodierung (application/x-www-form-urlencoded): Das Leerzeichen wird zu +.

Häufig gestellte Fragen

Werden meine Daten auf einen Server hochgeladen?
Nein. Kodierung und Dekodierung erfolgen vollständig in deinem Browser über die eingebauten JavaScript-Funktionen encodeURIComponent, decodeURIComponent, encodeURI und decodeURI. Deine Eingabe verlässt nie dein Gerät, und es wird keine Netzwerkanfrage gestellt.
Welche Zeichen gelten als 'sicher' und bleiben unkodiert?
RFC 3986 definiert die nicht reservierten Zeichen (A-Z, a-z, 0-9, Bindestrich (-), Unterstrich (_), Punkt (.) und Tilde (~)) als stets sicher und nie kodiert. Im Voll-URI-Modus bleiben auch die reservierten Strukturzeichen (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) erhalten, weil sie in einer vollständigen URL syntaktische Bedeutung tragen.
Was ist der Unterschied zwischen den beiden Modi?
Der Komponentenmodus (encodeURIComponent) ist dafür gedacht, einzelne Abfrageparameter-Werte oder Pfadsegmente zu kodieren. Er escapt alles außer den nicht reservierten Zeichen, sodass ein kaufmännisches Und innerhalb eines Werts zu %26 wird und nicht mit einem Parametertrenner verwechselt wird. Der Voll-URI-Modus (encodeURI) ist für vollständige URLs gedacht: Er bewahrt die reservierten Strukturzeichen, damit die URL nach der Kodierung gültig und analysierbar bleibt.
Warum wird ein Leerzeichen manchmal zu + und manchmal zu %20?
Das hängt vom Kontext ab. Das von HTML-Formularen verwendete Format application/x-www-form-urlencoded kodiert Leerzeichen aus historischen Gründen als +. Die strikte Prozentkodierung nach RFC 3986 verwendet überall sonst %20 für Leerzeichen, auch in Pfadsegmenten und modernen Abfragezeichenketten. Im Zweifel ist %20 die sichere Wahl; + sollte nur innerhalb eines Formularkörpers als Leerzeichen dekodiert werden, nicht in einem URL-Pfad.
Gibt es Zeichen, die selbst kodiert nie in einer URL erscheinen dürfen?
Alle Bytes 0x00-0xFF lassen sich in einer URL per Prozentkodierung darstellen, technisch ist also jede Bytefolge ausdrückbar. Es gibt jedoch praktische Grenzen: Sehr lange URLs (über 2000 Zeichen) können von Browsern, Servern oder Proxys abgelehnt werden. Internationalisierte Domainnamen (IDN) verwenden für den Host-Teil einer URL Punycode statt Prozentkodierung.
Verarbeitet dieses Tool Unicode und Emoji korrekt?
Ja. Die JavaScript-Funktion encodeURIComponent wandelt Zeichen in ihre UTF-8-Bytefolge um, bevor sie jedes Byte prozentkodiert, was nach RFC 3986 das korrekte Verhalten ist. Das Eurozeichen € (U+20AC) wird zum Beispiel zu %E2%82%AC, den drei Bytes seiner UTF-8-Kodierung. Emoji und jeder andere Unicode-Codepunkt werden genauso behandelt.
Kann ich damit eine doppelt kodierte URL dekodieren?
Du kannst die Dekodierung mehrmals anwenden, indem du die Ausgabe wieder als Eingabe einfügst. Doppelte Kodierung tritt auf, wenn eine bereits kodierte Zeichenkette erneut kodiert wird und %20 zu %2520 wird (das % selbst wird zu %25). Wenn du in einer dekodierten URL wörtliche %25-Sequenzen siehst, war der ursprüngliche Wert doppelt kodiert und du musst ihn ein zweites Mal dekodieren.
Ist URL-Kodierung dasselbe wie HTML-Entity-Kodierung?
Nein. Das sind getrennte Systeme. Die URL-Kodierung verwendet Prozentkodierung (%20, %26 usw.), um Zeichen innerhalb von URIs sicher zu machen. Die HTML-Entity-Kodierung verwendet benannte oder numerische Referenzen (&,   usw.), um Zeichen mit besonderer Bedeutung im HTML-Markup zu escapen. Sie werden manchmal verwechselt, weil beide & in einer URL zu %26 und in HTML zu & umwandeln, doch sie sollten nie vermischt werden.
Was ist der Unterschied zwischen einem URI und einer URL?
Ein URI (Uniform Resource Identifier) ist das breitere Konzept: eine Zeichenkette, die eine Ressource nach Name, Ort oder beidem identifiziert. Eine URL (Uniform Resource Locator) ist eine besondere Art von URI, die das Mittel zur Lokalisierung der Ressource liefert; sie umfasst ein Schema (https://), einen Host und einen Pfad. In der täglichen Webentwicklung werden die Begriffe austauschbar verwendet, doch technisch ist jede URL ein URI, während nicht jeder URI eine URL ist.
Warum erzeugt das Kodieren einer bereits kodierten Zeichenkette unleserliche Ausgabe?
Weil das Prozentzeichen (%) selbst als %25 kodiert wird, verwandelt das Kodieren einer bereits kodierten Zeichenkette jede %XX-Sequenz in %25XX. Zum Beispiel wird %20 zu %2520. Dekodiere immer zuerst, wenn du nicht sicher bist, ob die Eingabe bereits kodiert ist, statt sie erneut zu kodieren. Der Dekodiermodus dieses Tools stellt die ursprüngliche Zeichenkette aus einer einzigen Kodierungsstufe wieder her.

Über URL kodieren / dekodieren

Die URL-Kodierung ist unvermeidlich, sobald du Webadressen programmatisch erstellst oder analysierst. Abfragezeichenketten-Werte mit Leerzeichen, kaufmännischem Und oder Gleichheitszeichen würden die Parameterauswertung zerstören, blieben sie unkodiert. Formularübermittlungen verwenden standardmäßig application/x-www-form-urlencoded, das alles per Prozent kodiert und Leerzeichen in + umwandelt. REST-API-Clients müssen Pfadsegmente mit Schrägstrichen oder Fragezeichen kodieren, damit der Server sie nicht als Strukturzeichen interpretiert. Webhook-Nutzlasten, OAuth-Weiterleitungs-URIs und Deeplinks beruhen alle auf sorgfältiger Kodierung und Dekodierung, um Daten ohne Mehrdeutigkeit zu übergeben.

Dieses Tool erledigt die Prozentkodierung und -dekodierung vollständig in deinem Browser. Es bietet zwei Modi passend zu den beiden Standard-JavaScript-Funktionen. Der Komponentenmodus (entspricht encodeURIComponent) ist für einzelne Werte gedacht (einen Suchbegriff, einen Dateinamen, einen OAuth-Parameter) und escapt alles außer den nicht reservierten Zeichen A-Z, a-z, 0-9, Bindestrich, Unterstrich, Punkt und Tilde. Der Voll-URI-Modus (entspricht encodeURI) bewahrt die Strukturzeichen einer vollständigen URL (Doppelpunkt, Schrägstrich, Fragezeichen, Rautezeichen, kaufmännisches Und, Gleichheitszeichen) und ist nützlich, wenn du eine URL normalisieren willst, ohne ihre Struktur zu zerstören. Da alles lokal läuft, wird keine Eingabe je an einen Server gesendet.

Ein häufiger Fehler ist, eine ganze URL mit encodeURIComponent zu kodieren: Das escapt die Doppelpunkte und Schrägstriche und erzeugt eine kaputte Adresse. Verwende den Komponentenmodus nur für einzelne Werte, bevor du sie zu einer URL zusammensetzt. Umgekehrt führt das Vergessen, Werte mit & oder = innerhalb von Abfragezeichenketten zu kodieren, dazu, dass Parameter am empfangenden Ende stillschweigend aufgeteilt oder zusammengeführt werden. Beachte außerdem, dass das Zeichen + nur innerhalb von application/x-www-form-urlencoded-Körpern ein Leerzeichen bedeutet; in Pfadsegmenten muss ein wörtliches + als %2B prozentkodiert werden.

Woher die Prozentkodierung ihren Namen hat

Die Prozentkodierung verdankt ihren Namen dem wörtlichen Prozentzeichen (%), das sie als Escape-Zeichen verwendet. Als Tim Berners-Lee 1990 am CERN die URL-Syntax definierte, brauchte er eine Möglichkeit, beliebige Bytes darzustellen, die in ASCII-Text eindeutig wäre. Er wählte %, weil es druckbar war, in Bezeichnern selten verwendet wurde und sich optisch abhob, was kodierte Sequenzen auf einen Blick erkennbar machte.

Die ursprüngliche URL-Spezifikation (RFC 1738, 1994) verlangte bereits die Prozentkodierung unsicherer Zeichen, doch verschiedene Systeme waren uneins darüber, welche Zeichen 'unsicher' waren und wie mit Unicode umzugehen sei. Es dauerte bis 2005 und bis RFC 3986, bis ein endgültiger Standard entstand, zusammen mit einem Begleitdokument (RFC 3987), das IRIs (Internationalized Resource Identifiers) definierte, die Unicode-Zeichen direkt in der Syntax erlauben.

Heute liefert praktisch jede Programmiersprache eine URL-Kodierfunktion in ihrer Standardbibliothek, doch feine Unterschiede bleiben: PHPs urlencode() kodiert Leerzeichen als +, Pythons urllib.parse.quote() verwendet %20, und JavaScripts encodeURIComponent() folgt RFC 3986. Diese Vielfalt ist der Grund, warum sprachübergreifende API-Integrationen manchmal mit Kodierungs-Unstimmigkeiten kämpfen: Dasselbe Zeichen kann je nach serialisierender Bibliothek völlig anders aussehen.

Verwandte Tools

Base64-Encoder und -Decoder

Kodiere und dekodiere Text oder Dateien lokal in deinem Browser als Base64.

JSON-Validator und -Formatierer

Validiere, formatiere und minifiziere JSON in deinem Browser mit genauen Fehlerpositionen.

Basic-Auth-Header-Generator

Erstelle und dekodiere HTTP-Basic-Authentifizierungs-Header aus einem Benutzernamen und einem Passwort, vollständig in deinem Browser.

Bcrypt-Generator und -Verifizierer

Erzeuge bcrypt-Passwort-Hashes und prüfe ein Passwort gegen einen vorhandenen Hash, vollständig in deinem Browser.
Unterstützen