Kostenloser URL-Encoder / -Decoder

Kodieren oder dekodieren Sie URLs und URI-Komponenten sofort.

Keine Daten verlassen Ihr Gerät

encodeURIComponent encodeURI

Eingabe

Ausgabe

Was URL-Kodierung tatsächlich tut

URL-Kodierung (auch Prozent-Kodierung genannt) ist der Mechanismus, mit dem das Web beliebige Zeichendaten in eine URL einpasst. URLs wurden ursprünglich für ein winziges ASCII-Alphabet entworfen (Buchstaben, Ziffern und eine kleine Menge von Satzzeichen) und Zeichen außerhalb dieses Alphabets (Leerzeichen, akzentuierte Buchstaben, Ampersands, Schrägstriche, die keine Pfadtrenner sind, Emojis, alles Kyrillische, CJK oder Arabische) müssen escaped werden, bevor sie sicher durch HTTP, Server-Logs, Adressleisten, Copy-Paste-Handler und Shell-Pipes reisen können. Die Kodierungsregel ist geradlinig: Man nimmt die UTF-8-Bytefolge des Zeichens und schreibt jedes Byte als Prozentzeichen gefolgt von zwei hexadezimalen Ziffern. Ein Leerzeichen (ein Byte, 0x20) wird zu %20. Ein Ampersand (0x26) wird zu %26. Das Eurozeichen € (drei UTF-8-Bytes E2 82 AC) wird zu %E2%82%AC. Die kodierte Form ist umkehrbar (jeder URL-Parser im Web versteht, wie man sie dekodiert) und das Ergebnis ist eine Zeichenkette, die nur „sichere“ ASCII-Zeichen enthält.

Eine kurze Geschichte der Kodierungsregel

Die Konvention der Prozent-Kodierung geht zurück auf RFC 1738 („Uniform Resource Locators (URL)“, Tim Berners-Lee, Larry Masinter und Mark McCahill, Dezember 1994), die erste formale URL-Spezifikation, die von der IETF veröffentlicht wurde. RFC 1738 definierte den ursprünglichen Satz „reservierter“ Zeichen (Zeichen mit struktureller Bedeutung in URLs, die kodiert werden müssen, wenn sie als Daten verwendet werden) und den ursprünglichen „unreservierten“ Satz (Zeichen, die nie kodiert werden müssen). Die Spezifikation wurde wesentlich überarbeitet in RFC 2396 (Berners-Lee, Fielding, Masinter, August 1998) und erneut (endgültig) in RFC 3986 („Uniform Resource Identifier (URI): Generic Syntax“, Berners-Lee, Fielding, Masinter, Januar 2005), die heute noch die formale URI-Spezifikation ist. RFC 3986 erweiterte den unreservierten Satz um das Tilde-Zeichen (~), formalisierte UTF-8 als Kodierung für Nicht-ASCII-Zeichen in IRIs und verschärfte die Regeln, wann reservierte Zeichen prozent-kodiert werden müssen und wann sie unverändert bleiben. Für Nicht-ASCII-URIs definierte RFC 3987 („Internationalized Resource Identifiers“, Duerst und Suignard, Januar 2005) die IRI-Erweiterung, die es URLs erlaubt, native Unicode-Zeichen zu enthalten, indem die IRI-Form über UTF-8 + Prozent-Kodierung auf die Standard-URI-Form abgebildet wird. Speziell für Domainnamen definierte RFC 3492 Punycode (Costello, März 2003), die Kodierung, die zur Darstellung von Unicode-Domain-Labels (xn--exmpla-...) im DNS verwendet wird, strukturell ähnlich, aber mit einem anderen Algorithmus. Die De-facto-URL-Spezifikation des modernen Webs ist der WHATWG URL Living Standard, herausgegeben von Anne van Kesteren, der das tatsächliche Verhalten von Browsern kodiert, manchmal abweichend von RFC 3986 zugunsten der Rückwärtskompatibilität mit der Funktionsweise von URLs in der Praxis.

Reserviert, unreserviert und die Zeichen, die immer kodiert werden

RFC 3986 teilt URI-Zeichen in drei Klassen ein. Unreservierte Zeichen: Buchstaben A-Z a-z, Ziffern 0-9 und die vier Zeichen - _ . ~: brauchen nie eine Kodierung und gewinnen auch keine Bedeutung, wenn sie kodiert werden. Reservierte Zeichen: : / ? # [ ] @ ! $ & ' ( ) * + , ; =: haben strukturelle Bedeutung in URLs (der Schrägstrich trennt Pfadsegmente, das Fragezeichen leitet die Query ein, das Ampersand trennt Query-Parameter, das Hash leitet das Fragment ein). Reservierte Zeichen können in ihrer strukturellen Rolle unkodiert auftreten; sie müssen kodiert werden, wenn sie als gewöhnliche Daten verwendet werden. Alle anderen Zeichen: Steuerzeichen, Leerzeichen, das Prozentzeichen selbst und jedes Byte einer Nicht-ASCII-UTF-8-Sequenz, müssen immer prozent-kodiert werden. Das Prozentzeichen ist besonders: es muss als %25 kodiert werden, wenn es als Daten erscheint, denn ein unkodiertes Prozent in einem URL-Kontext leitet eine prozent-kodierte Escape-Sequenz ein, die der Parser zu dekodieren versucht. Diesen Schritt zu überspringen erzeugt einige der häufigsten URL-Handhabungsbugs in freier Wildbahn.

encodeURI vs. encodeURIComponent, wann welches

JavaScript bringt zwei eingebaute Encoder mit, beide seit 1999 (ES3) in ECMAScript standardisiert. Die Wahl zwischen ihnen ist die häufigste URL-Kodierungsentscheidung in Webcode, und sie falsch zu treffen, erzeugt subtile Bugs, die Tests mit einfachen Eingaben bestehen, aber bei realen Benutzerdaten mit Ampersands, Hashes oder Schrägstrichen brechen.

encodeURIComponent: kodiert alles außer dem unreservierten Satz. Verwenden Sie das, wenn Sie ein einzelnes Datum kodieren, das in eine URL eingebettet wird, den Wert eines Query-Parameters, ein Pfadsegment, einen Fragment-Identifier, den Wert eines Formularfelds. Die Zeichenkette hello world&more wird zu hello%20world%26more: das Ampersand im Inneren wird kodiert, sodass es nicht als Query-Parameter-Trenner interpretiert wird, wenn die URL später gelesen wird. Das ist das richtige Werkzeug für „Ich habe eine Benutzereingabe und möchte sie sicher in eine URL stecken“.
encodeURI: kodiert nur die Zeichen, die überall in einer URL ungültig sind. Es lässt die reservierten Zeichen (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) absichtlich intakt, weil diese Zeichen strukturelle Arbeit leisten könnten. Verwenden Sie das, wenn Sie eine ganze URL kodieren, deren Struktur bereits steht, eine URL mit ihren eigenen ?- und &-Trennern, eine URL mit Nicht-ASCII-Zeichen im Pfad oder in der Query, die kodiert werden müssen, ohne die URL-Grammatik zu stören. Die Zeichenkette https://example.com/search?q=hello world wird zu https://example.com/search?q=hello%20world: die Schrägstriche und das Fragezeichen bleiben erhalten, nur das Leerzeichen wird kodiert.

Die Faustregel: encodeURIComponent für Daten, encodeURI für URLs. Verwenden Sie die falsche Funktion und Sie zerstören entweder die URL-Struktur (encodeURIComponent auf eine ganze URL escaped die Schrägstriche und Ampersands, die Sie brauchten) oder Sie escapen die Benutzereingabe nicht (encodeURI auf einen Query-Wert lässt Ampersands durch und Ihre Daten werden als mehrere Parameter geparst).

application/x-www-form-urlencoded, die andere Kodierung

Es gibt eine zweite, verwandte Kodierung, die speziell für HTML-Formularübermittlungen verwendet wird: application/x-www-form-urlencoded. Sie sieht der URL-Prozent-Kodierung fast identisch aus, bis auf ein Detail, Leerzeichen werden als + statt %20 kodiert. Diese Konvention stammt aus der ursprünglichen HTML-Formular-Spezifikation und ist im URL Living Standard speziell für den application/x-www-form-urlencoded-Serialisierer erhalten geblieben. Decoder für formularkodierte Daten müssen die Konvention umkehren: ein wörtliches + in Formulardaten wird als %2B kodiert, und ein + in der kodierten Zeichenkette dekodiert sich zurück zu einem Leerzeichen. Die URLSearchParams-API von JavaScript handhabt diese Konvention automatisch; encodeURIComponent tut das nicht: es kodiert Leerzeichen immer als %20. Für Query-Strings, die von Hand für eine HTML-Formularaktion zusammengebaut werden, verwenden Sie URLSearchParams, statt encodeURIComponent auf jeden Wert einzeln aufzurufen.

Wann Sie dieses Werkzeug tatsächlich brauchen

Debuggen eines API-Aufrufs. Sie sprechen einen REST-Endpunkt mit einem Query-Parameter an, der Leerzeichen oder Sonderzeichen enthält, und erhalten 400-Fehler oder unerwartete Ergebnisse. Kodieren Sie hier den Parameterwert, fügen Sie das Ergebnis in Ihre Anfrage ein und bestätigen Sie, dass die API die Eingabe korrekt behandelt.
Eine teilbare URL von Hand bauen. Einen Deep-Link zu einer Suchergebnisseite, einer gefilterten Ansicht eines SaaS-Dashboards oder einem vorbefüllten Formular zusammensetzen, überall dort, wo Sie eine Suchanfrage oder einen Auswahlzustand in die URL einbetten müssen.
Eine erfasste URL dekodieren, um zu lesen, was wirklich drinsteht. Eine geloggte URL enthält %E2%9C%93%20done: was ergibt das dekodiert? Einfügen, auf Dekodieren klicken, ✓ done sehen.
OAuth- und Webhook-URLs. Der Parameter redirect_uri in OAuth-Flows muss präzise prozent-kodiert sein; ein Fehler erzeugt undurchsichtige „redirect_uri mismatch“-Fehler. Webhook-URLs, die Query-Parameter mit Benutzerdaten enthalten, brauchen sorgfältige Kodierung.
Dateinamen mit Nicht-ASCII-Zeichen in Download-Links. Ein direkter Link zu einer Datei namens café-menu.pdf braucht das é prozent-kodiert, damit der Link in allen Browsern und Shell-Werkzeugen funktioniert.
Datenbank-Verbindungszeichenfolgen. URLs für PostgreSQL, MySQL und ähnliche Datenbanken (postgres://user:p@ssw0rd@host/db) brauchen das Passwort prozent-kodiert, wenn es @, :, / oder andere reservierte Zeichen enthält, die den URL-Parser verwirren würden.

Sicherheit: Warum Kodierung mehr als Ästhetik ist

Falsche URL-Kodierung ist eine alte Quelle von Web-Schwachstellen. HTTP Response Splitting nutzt unkodierte Zeilenumbrüche (CR, LF, %0D%0A) in URL-Parametern aus, die in HTTP-Header gespiegelt werden, sodass ein Angreifer beliebige Header oder sogar eine vollständige Antwort einschleusen kann. Open Redirects nutzen naive URL-Behandlung aus, die vom Benutzer gelieferte URLs nicht richtig dekodiert und validiert, bevor weitergeleitet wird. Server-Side Request Forgery (SSRF) kann kodierte Zeichen missbrauchen, um URL-Allowlists zu umgehen, ein Regex, der „http://internal“ blockiert, übersieht „http://%69nternal“, wenn der Server nach der Regex-Prüfung dekodiert. SQL-Injection über URL-Parameter ist an sich kein URL-Kodierungsproblem, wird aber verschärft, wenn einfache Anführungszeichen und andere SQL-Metazeichen bis in die Datenbankanfrage überleben. Die OWASP-Empfehlung seit Anfang der 2000er lautet: an der Grenze beim Eingang kodieren, an der Grenze beim Ausgang dekodieren, niemals kodierte und dekodierte Formen im selben Puffer mischen. Dieses Werkzeug macht genau den Schritt Kodieren/Dekodieren, was Sie mit dem Ergebnis tun, liegt bei Ihnen, und die Sicherheitsverantwortung liegt auf der Anwendungsebene.

Doppelte Kodierung, der häufigste Fehler

Doppelte Kodierung passiert, wenn eine bereits kodierte Zeichenkette nochmals kodiert wird. Das Leerzeichen in einer bereits kodierten URL ist %20; kodiert man es erneut, erhält man %2520 (weil % zu %25 kodiert wird). Wenn der Empfänger einmal dekodiert, bekommt er %20 zurück statt eines Leerzeichens. Wenn er zweimal dekodiert (in den seltenen Fällen, in denen Doppel-Dekodierung unterstützt wird), erhält er das Leerzeichen, aber die meisten Parser tun das nicht, und die URL enthält stillschweigend ein sichtbares %20 in der Adressleiste. Die Lösung ist immer: zuerst dekodieren, wenn Sie nicht wissen, ob die Eingabe bereits kodiert ist, dann genau einmal kodieren. Dasselbe Muster gilt im Code, rufen Sie nie encodeURIComponent zweimal auf dieselbe Zeichenkette auf. Wenn Sie einen Wert von einem Kontext in einen anderen überführen müssen, dekodieren Sie die vorherige Kodierung, bevor Sie für den neuen Kontext erneut kodieren. Die Tausch-Schaltfläche dieses Werkzeugs hilft beim Diagnosezyklus: verdächtige URL einfügen, auf Dekodieren klicken, um zu sehen, was drinsteht, auf Tauschen klicken, auf Kodieren klicken, um die kanonische kodierte Form zurückzubekommen.

Privatsphäre: Ausführung nur im Browser

URLs enthalten häufig sensible Daten, Auth-Tokens in Query-Parametern, Benutzerkennungen in Pfadsegmenten, Suchanfragen mit persönlichem Kontext, OAuth-State-Werte, Webhook-URLs mit API-Schlüsseln. Serverseitige URL-Encoder behalten von jeder URL, die Sie einfügen, eine Kopie in ihren Logs. Dieses Werkzeug verwendet die in JavaScript eingebauten Funktionen encodeURIComponent, encodeURI, decodeURIComponent und decodeURI, die lokal in Ihrem Browser-Tab laufen. Kein Upload-Schritt, keine Telemetrie, kein Logging, überprüfen Sie es im Netzwerk-Tab der DevTools, während Sie auf Kodieren klicken (es werden keine Anfragen ausgelöst), oder schalten Sie die Seite nach dem Laden offline (Flugmodus), und der Encoder funktioniert weiter. Sicher für URLs mit Tokens, API-Schlüsseln, internen Endpunkten oder jeder URL, die Sie nicht auf der Festplatte eines Fremden sehen möchten.

Häufig gestellte Fragen

Wann sollte ich Text URL-kodieren?

Immer wenn Sie Benutzereingaben oder Daten mit Sonderzeichen in eine URL einbetten, Suchanfragen in einem Query-String, Dateinamen in einem Pfad, Parameterwerte in API-Anfragen, Weiterleitungsziele in OAuth-Flows. Ohne Kodierung zerstören Sonderzeichen entweder die URL-Struktur (ein nicht escaped & in einem Wert wird als Parameter-Trenner interpretiert) oder schaffen Sicherheitslücken (ein nicht escapeter Zeilenumbruch ermöglicht HTTP Response Splitting). Die Faustregel: jede Zeichenkette, die etwas anderes als Buchstaben, Ziffern und die vier Zeichen -_.~ enthält, braucht Kodierung, bevor sie in eine URL gelangt.

Was ist doppelte Kodierung und wie vermeide ich sie?

Doppelte Kodierung passiert, wenn bereits kodierter Text ein zweites Mal kodiert wird, sodass aus %20 %2520 wird (weil das Prozentzeichen selbst als %25 kodiert wird). Empfänger, die einmal dekodieren, bekommen die halbdekodierte Form zurück statt das Original. Immer: wenn Sie nicht wissen, ob eine Zeichenkette bereits kodiert ist, dekodieren Sie sie zuerst und kodieren Sie sie dann genau einmal. Im Code: rufen Sie nie encodeURIComponent auf die Ausgabe eines anderen encodeURIComponent auf.

Ist dieses Tool sicher für sensible URLs?

Ja. Der Encoder/Decoder verwendet die in JavaScript eingebauten Funktionen, die vollständig in Ihrem Browser laufen. Die URL, die Sie einfügen, verlässt nie das Netzwerk, überprüfen Sie es im Netzwerk-Tab der DevTools, während Sie auf Kodieren klicken (es werden keine Anfragen ausgelöst), oder schalten Sie die Seite nach dem Laden offline (Flugmodus). Sicher für URLs mit OAuth-Tokens, API-Schlüsseln, Adressen interner Endpunkte oder jeden Wert, den Sie nicht auf einem Drittanbieter-Server geloggt sehen möchten.

Warum haben meine Formulardaten Pluszeichen statt %20?

HTML-Formularübermittlungen verwenden eine separate, aber verwandte Kodierung namens application/x-www-form-urlencoded, die Leerzeichen aus historischer Konvention als + statt %20 kodiert. Beide Formen sind in URL-Query-Strings gültig; moderne Parser akzeptieren beide. Die URLSearchParams-API von JavaScript verwendet die Formular-Konvention; encodeURIComponent verwendet immer %20. Wenn Ihre Daten mit altem Formular-Handling-Code interoperieren müssen, verwenden Sie URLSearchParams; wenn nicht, funktioniert beides.

Was ist mit Nicht-ASCII-Zeichen und Emojis?

Moderne URL-Kodierung verwendet UTF-8: jedes Nicht-ASCII-Zeichen wird in seine UTF-8-Mehrbyte-Darstellung konvertiert, dann wird jedes Byte prozent-kodiert. Das Eurozeichen (€, drei UTF-8-Bytes) wird zu %E2%82%AC; ein Emoji wie die Rakete 🚀 (vier Bytes) wird zu %F0%9F%9A%80. RFC 3987 (IRIs) und der WHATWG URL Standard formalisieren beide diese UTF-8-zuerst-Konvention. Ältere Systeme verwendeten manchmal Latin-1 oder andere Kodierungen; wenn Sie alte URLs dekodieren und das Ergebnis wirr aussieht, hat die Quelle möglicherweise vor der Prozent-Kodierung eine andere Zeichenkodierung verwendet.