Skip to content

URL-Kodierer & -Dekodierer mit integriertem URL-Parser

URL einfügen zum Dekodieren oder Kodieren in Echtzeit. Integrierter URL-Parser zerlegt jede Komponente in bearbeitbare Felder. Dualmodus: encodeURI & encodeURIComponent. Privat — keine Daten an Server.

Kein Tracking Läuft im Browser Kostenlos
Dekodiert
Kodiert
Geprüft auf RFC-3986-Konformität, encodeURI/encodeURIComponent-Korrektheit und UTF-8-Kodierungsgenauigkeit — Go Tools Engineering Team · Apr 7, 2026

Was ist URL-Kodierung?

URL-Kodierung, formal als Prozentkodierung bezeichnet, ist ein in RFC 3986 definierter Mechanismus zur Darstellung von Zeichen in einem Uniform Resource Identifier (URI), die nicht erlaubt sind oder eine besondere Bedeutung haben. Dabei wird jedes unsichere Byte in ein Prozentzeichen (%) gefolgt von zwei Hexadezimalziffern umgewandelt — beispielsweise wird ein Leerzeichen zu %20, ein kaufmännisches Und zu %26 und das chinesische Zeichen 中 zu %E4%B8%AD (seine drei UTF-8-Bytes, jeweils prozentkodiert).

URLs dürfen nur eine begrenzte Menge an Zeichen aus dem ASCII-Zeichensatz enthalten. Buchstaben, Ziffern und eine Handvoll Symbole (- _ . ~) gelten als „nicht reserviert“ und dürfen unverändert erscheinen. Alle anderen Zeichen — einschließlich Leerzeichen, Satzzeichen und der gesamte Unicode-Bereich — müssen prozentkodiert werden, um sicher in einer URL übertragen werden zu können. Reservierte Zeichen wie ?, &, = und # dienen als strukturelle Trennzeichen in der URL-Syntax und müssen daher ebenfalls kodiert werden, wenn sie als buchstäbliche Daten und nicht als Trennzeichen verwendet werden.

Prozentkodierung ist im gesamten Web unverzichtbar: Browser kodieren Formularübermittlungen, APIs erfordern kodierte Query-Parameter, OAuth-Flows hängen von korrekt kodierten Redirect-URIs ab, und internationalisierte Domainnamen nutzen die Kodierung für Nicht-ASCII-Zeichen. Fehlerhafte Kodierung führt zu defekten Links, Sicherheitslücken (wie Open-Redirect-Angriffen) und Datenkorruption.

Dieses Tool bietet sowohl den encodeURI- als auch den encodeURIComponent-Modus, einen integrierten URL-Struktur-Parser, Echtzeitumwandlung und Erkennung doppelter Kodierung — alles privat in Ihrem Browser.

URL-Kodierung wird oft zusammen mit anderen Webentwicklungstools verwendet. Möglicherweise müssen Sie eine URL Base64-kodieren, um sie in ein JWT-Token oder eine API-Payload einzubetten, oder JSON-Daten formatieren, die URL-Zeichenketten enthalten, um deren Struktur zu untersuchen.

// Encode a query parameter value
const param = encodeURIComponent('hello world & goodbye');
console.log(param); // → 'hello%20world%20%26%20goodbye'

// Encode a full URL (preserves structure)
const url = encodeURI('https://example.com/path name?q=hello world');
console.log(url); // → 'https://example.com/path%20name?q=hello%20world'

// Decode a percent-encoded string
const decoded = decodeURIComponent('hello%20world%20%26%20goodbye');
console.log(decoded); // → 'hello world & goodbye'

// Build a URL with encoded parameters
const base = 'https://api.example.com/search';
const query = `?q=${encodeURIComponent('你好')}&lang=zh`;
console.log(base + query); // → 'https://api.example.com/search?q=%E4%BD%A0%E5%A5%BD&lang=zh'

Hauptfunktionen

Zwei Kodierungsmodi

Wechseln Sie zwischen encodeURI (bewahrt die URL-Struktur) und encodeURIComponent (kodiert alles für Parameterwerte), um genau Ihren Anwendungsfall abzudecken.

Integrierter URL-Parser

Zerlegt automatisch jede URL in Protokoll, Host, Port, Pfad, Query-Parameter und Fragment — jedes Feld ist bearbeitbar und kann zu einer neuen URL zusammengesetzt werden.

Echtzeitumwandlung

Kodieren und dekodieren Sie sofort beim Tippen — kein Klick auf Schaltflächen nötig, Ergebnisse erscheinen mit jedem Tastenanschlag im anderen Bereich.

100 % browserbasiert

Die gesamte Verarbeitung erfolgt lokal in Ihrem Browser mit nativen JavaScript-APIs. Ihre Daten verlassen niemals Ihr Gerät — kein Server-Upload, kein Tracking.

Volle UTF-8-Unterstützung

Verarbeitet korrekt chinesische, japanische, koreanische, arabische Zeichen, Emoji und jeden Unicode-Text durch ordnungsgemäße UTF-8-Byte-Kodierung und -Dekodierung.

Erkennung doppelter Kodierung

Erkennt automatisch und warnt vor Problemen mit doppelter Kodierung wie %2520 (ein prozentkodiertes %20), und hilft Ihnen, einen der häufigsten URL-Kodierungsfehler zu vermeiden.

Beispiele

Verstümmelte URL dekodieren

https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dhello%20world%26lang%3Den
https://example.com/search?q=hello world&lang=en

Eine vollständig prozentkodierte URL wird in ihre lesbare Form zurückverwandelt, sodass die ursprünglichen Query-Parameter und die Struktur sichtbar werden

Chinesische Zeichen

https://example.com/search?q=你好世界
https://example.com/search?q=%E4%BD%A0%E5%A5%BD%E4%B8%96%E7%95%8C

Chinesische Zeichen werden in ihre UTF-8-Bytefolgen umgewandelt und prozentkodiert

Query-Parameter

https://example.com/api?name=John Doe&role=admin&lang=en&sort=date desc
https://example.com/api?name=John%20Doe&role=admin&lang=en&sort=date%20desc

Leerzeichen und Sonderzeichen in Query-Parameter-Werten werden prozentkodiert, während die URL-Struktur erhalten bleibt

Vollständige URL

https://user:pass@example.com:8080/path/to/page?key=value&arr[]=1#section-2
https://user:pass@example.com:8080/path/to/page?key=value&arr%5B%5D=1#section-2

Eine vollständige URL mit Anmeldedaten, Port, Pfad, Query-Parametern mit eckigen Klammern und einem Fragment-Bezeichner

OAuth-Redirect-URI

https://auth.example.com/authorize?redirect_uri=https://myapp.com/callback?code=abc&state=xyz
https://auth.example.com/authorize?redirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback%3Fcode%3Dabc%26state%3Dxyz

Der Wert von redirect_uri enthält selbst eine vollständige URL, die kodiert werden muss, damit ihre Sonderzeichen nicht als Teil der äußeren URL interpretiert werden

Anleitung

  1. 1

    URL oder kodierten String eingeben

    Fügen Sie eine URL im dekodierten Bereich ein, um sie zu kodieren, oder fügen Sie eine prozentkodierte Zeichenkette im kodierten Bereich ein, um sie zu dekodieren. Wählen Sie je nach Anwendungsfall den Modus encodeURI oder encodeURIComponent.

  2. 2

    Ergebnisse und geparste Struktur anzeigen

    Der andere Bereich aktualisiert sich sofort beim Tippen. Der URL-Parser zerlegt die URL in Protokoll, Host, Port, Pfad, Query-Parameter und Fragment — alles bearbeitbar.

  3. 3

    Kopieren oder neu erstellen

    Klicken Sie auf „Kopieren“, um das kodierte oder dekodierte Ergebnis zu kopieren. Bearbeiten Sie einzelne URL-Komponenten und klicken Sie auf „Neu erstellen“, um eine neue URL aus den geänderten Teilen zusammenzusetzen.

Häufige Fehler

Doppelte Kodierung (%2520 statt %20)

Doppelte Kodierung tritt auf, wenn eine bereits kodierte URL erneut kodiert wird. Das % in %20 wird zu %25 kodiert, wodurch %20 zu %2520 wird. Dies bricht die URL, da der Server die buchstäbliche Zeichenkette %20 statt eines Leerzeichens sieht.

✗ Falsch
https://example.com/path%2520with%2520spaces
✓ Richtig
https://example.com/path%20with%20spaces

Leerzeichen als + in Pfadsegmenten kodiert

Das +-Zeichen steht nur im application/x-www-form-urlencoded-Format (Query-Strings aus HTML-Formularen) für ein Leerzeichen. In URL-Pfadsegmenten wird + als buchstäbliches Pluszeichen interpretiert, nicht als Leerzeichen. Verwenden Sie für Leerzeichen in Pfadsegmenten immer %20.

✗ Falsch
https://example.com/my+file+name.pdf
✓ Richtig
https://example.com/my%20file%20name.pdf

encodeURI für Query-Parameter-Werte verwenden

encodeURI() kodiert &, = und andere reservierte Zeichen nicht. Die Verwendung auf einem Parameterwert, der diese Zeichen enthält, beschädigt die Query-String-Struktur.

✗ Falsch
encodeURI('key=value&more')  → 'key=value&more' (& not encoded!)
✓ Richtig
encodeURIComponent('key=value&more')  → 'key%3Dvalue%26more'

Nicht-UTF-8-Kodierung angenommen

Einige ältere Systeme verwenden Kodierungen wie Latin-1 oder Shift-JIS für URL-Parameter. Moderne Standards erfordern UTF-8. Die Dekodierung eines Shift-JIS-kodierten Parameters mit einem UTF-8-Decoder erzeugt beschädigten Text.

✗ Falsch
Decoding %82%B1%82%F1 as UTF-8 (this is Shift-JIS for こん)
✓ Richtig
Using UTF-8: %E3%81%93%E3%82%93 correctly decodes to こん

Relative Pfade ohne Kontext kodieren

Die Kodierung eines relativen Pfads wie ../images/photo.jpg mit encodeURIComponent wandelt Schrägstriche und Punkte in prozentkodierte Sequenzen um und zerstört die Pfadstruktur. Verwenden Sie encodeURI() oder kodieren Sie nur die einzelnen Pfadsegmente.

✗ Falsch
encodeURIComponent('../images/photo.jpg')  → '..%2Fimages%2Fphoto.jpg'
✓ Richtig
Encode each segment: '../images/' + encodeURIComponent('my photo.jpg')

Häufige Anwendungsfälle

Verstümmelte URLs debuggen
Prozentkodierte URLs aus Server-Logs, Fehlermeldungen oder Browser-Entwicklertools dekodieren, um den ursprünglichen, lesbaren Text zu sehen.
API-Entwicklung
Query-Parameter-Werte für REST-API-Aufrufe kodieren und sicherstellen, dass Sonderzeichen wie &, = und Leerzeichen die Anfrage-URL nicht beschädigen.
OAuth-Flow-Einrichtung
redirect_uri und andere URL-Parameter in OAuth-Autorisierungs-URLs korrekt kodieren, um Authentifizierungsfehler zu vermeiden.
Internationalisierte URLs
URLs mit chinesischen, japanischen, koreanischen, arabischen oder anderen Nicht-ASCII-Zeichen für internationalisierte Webanwendungen kodieren und dekodieren.
Marketing-Link-Analyse
Tracking-URLs aus E-Mail-Kampagnen und Werbeplattformen dekodieren, um die eingebetteten UTM-Parameter und Weiterleitungsketten zu verstehen.
URL-Struktur untersuchen
Komplexe URLs in ihre Bestandteile zerlegen — Protokoll, Host, Port, Pfad, Query-Parameter und Fragment — zur Analyse und Bearbeitung.

Technische Details

RFC 3986 — Reservierte und nicht reservierte Zeichen
RFC 3986 definiert nicht reservierte Zeichen (A-Z, a-z, 0-9, -, ., _, ~), die niemals kodiert werden müssen, sowie reservierte Zeichen (:, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ,, ;, =), die als URI-Trennzeichen dienen und prozentkodiert werden müssen, wenn sie als Daten verwendet werden.
UTF-8-Byte-Kodierungsablauf
Nicht-ASCII-Zeichen werden zunächst in ihren Unicode-Codepunkt umgewandelt, dann als UTF-8-Bytes kodiert (1-4 Bytes je nach Codepunkt-Bereich) und schließlich wird jedes Byte als %XX prozentkodiert. Beispiel: é (U+00E9) → UTF-8-Bytes C3 A9 → %C3%A9. Das Emoji 🎉 (U+1F389) → UTF-8-Bytes F0 9F 8E 89 → %F0%9F%8E%89.
URL vs. URI — Begriffsklärung
Eine URI (Uniform Resource Identifier) ist der allgemeine Begriff für jede Bezeichnerzeichenkette. Eine URL (Uniform Resource Locator) ist eine URI, die zusätzlich den Zugriffsmechanismus angibt (wie https://). Die Kodierungsregeln in RFC 3986 gelten für alle URIs. Die JavaScript-API verwendet die URI-Terminologie (encodeURI, decodeURI), während im Alltag der Begriff URL bevorzugt wird.

Best Practices

Den richtigen Modus verwenden
Verwenden Sie encodeURIComponent() für einzelne Query-Parameter-Schlüssel und -Werte. Verwenden Sie encodeURI() nur, wenn Sie eine vollständige URL haben und unsichere Zeichen kodieren möchten, ohne die Struktur zu zerstören. Verwenden Sie encodeURI() niemals für Parameterwerte, die &, = oder andere reservierte Zeichen enthalten können.
Doppelte Kodierung vermeiden
Prüfen Sie vor dem Kodieren einer Zeichenkette, ob sie bereits kodiert ist. Suchen Sie nach vorhandenen %-Sequenzen. Die Kodierung einer bereits kodierten Zeichenkette macht aus %20 → %2520, aus %3D → %253D usw. Wenn Sie unsicher sind, dekodieren Sie zuerst und kodieren Sie dann einmal.
Serverseitig dekodieren
Die meisten Web-Frameworks dekodieren URL-Parameter automatisch, bevor Ihr Anwendungscode sie sieht. Vermeiden Sie die manuelle Dekodierung von Parametern, die Ihr Framework bereits dekodiert hat — dies kann Probleme verursachen, wenn der ursprüngliche Wert buchstäbliche Prozentsequenzen enthielt.
Werte für OAuth und API-Signierung kodieren
OAuth 1.0 Signatur-Basis-Strings und viele API-Signierungsalgorithmen erfordern strikte RFC-3986-Prozentkodierung. Verwenden Sie encodeURIComponent() und ersetzen Sie dann verbleibende Zeichen, die nicht kodiert werden (wie !, ', (, ), *), durch ihre prozentkodierten Entsprechungen, wenn die Spezifikation dies erfordert.

Häufig gestellte Fragen

Was ist URL-Kodierung und warum ist sie notwendig?
URL-Kodierung (Prozentkodierung) wandelt unsichere Zeichen in %XX-Hexadezimalfolgen um, damit sie sicher in URLs verwendet werden können. Zeichen wie Leerzeichen, kaufmännische Und-Zeichen und Nicht-ASCII-Text müssen kodiert werden, da sie sonst die URL-Struktur beschädigen oder von Browsern und Servern falsch interpretiert würden. Dieser in RFC 3986 definierte Mechanismus funktioniert, weil URLs nur eine begrenzte Menge an US-ASCII-Zeichen enthalten dürfen — Buchstaben (A-Z, a-z), Ziffern (0-9) und einige wenige Symbole wie Bindestrich, Unterstrich, Punkt und Tilde. Jedes Zeichen außerhalb dieses sicheren Zeichensatzes wird als Prozentzeichen (%) gefolgt von zwei Hexadezimalziffern kodiert, die den Bytewert des Zeichens darstellen. So wird beispielsweise ein Leerzeichen zu %20, ein Schrägstrich zu %2F und ein kaufmännisches Und zu %26. Zeichen wie &, =, ? und # haben eine besondere strukturelle Bedeutung in URLs — sie trennen Query-Parameter, Fragmente und andere Bestandteile. Ohne Kodierung würde ein buchstäbliches & in einem Parameterwert als Parametertrenner fehlinterpretiert und die URL-Struktur vollständig zerstören.
Was ist der Unterschied zwischen encodeURI und encodeURIComponent?
encodeURI() kodiert eine vollständige URL und bewahrt dabei strukturelle Zeichen wie :, /, ? und #. encodeURIComponent() kodiert alles außer Buchstaben, Ziffern und - _ . ~, was es zur richtigen Wahl für die Kodierung einzelner Query-Parameter-Werte macht. Verwenden Sie encodeURIComponent() für Parameterschlüssel und -werte und encodeURI() nur für vollständige URLs. Beispiel: encodeURI('https://example.com/path name') ergibt 'https://example.com/path%20name' — :// und / bleiben erhalten. encodeURIComponent() ist weitaus aggressiver — es kodiert :, /, ?, #, & und =. Würden Sie encodeURI() auf einen Parameterwert mit einem kaufmännischen Und anwenden, würde das & unkodiert durchgereicht und als Parametertrenner fehlinterpretiert. encodeURIComponent() würde es korrekt als %26 kodieren. Diese Verwechslung ist eine der häufigsten Ursachen für URL-bezogene Fehler in Webanwendungen.
Ist URL-Kodierung dasselbe wie HTML-Kodierung?
Nein. URL-Kodierung wandelt Zeichen in %XX-Hexadezimalfolgen für URLs um (RFC 3986), während HTML-Kodierung Zeichen in Entitäten wie & und < für HTML-Dokumente umwandelt. Sie dienen völlig unterschiedlichen Zwecken und sollten niemals vertauscht werden. URL-Kodierung dient dem Datentransport innerhalb von URLs — ein Leerzeichen wird zu %20. HTML-Kodierung dient der sicheren Darstellung von Inhalten in HTML — ein kaufmännisches Und wird zu &. Ein häufiger Fehler ist die Anwendung von HTML-Kodierung auf URL-Parameter oder umgekehrt. Beispielsweise würde die Kodierung eines Leerzeichens als   in einer URL nicht funktionieren — es muss %20 oder + sein. Ebenso würde die Verwendung von %3C im HTML-Text anstelle von < nicht die gewünschte Maskierung erreichen.
Warum bricht meine URL ab, wenn ich sie in einem curl-Befehl verwende?
Die Shell interpretiert spezielle URL-Zeichen, bevor curl sie sieht: & führt Befehle im Hintergrund aus, ? löst Globbing aus und # leitet einen Kommentar ein. Lösung: Umschließen Sie die URL mit einfachen Anführungszeichen: curl 'https://example.com/api?key=value&page=2#section'. Einfache Anführungszeichen verhindern, dass die Shell Sonderzeichen interpretiert. Das kaufmännische Und (&) ist der häufigste Problemverursacher — es weist die Shell an, den vorangehenden Befehl im Hintergrund auszuführen, wobei die URL beim ersten & aufgeteilt und alles danach verworfen wird. Alternativ können Sie einzelne Zeichen mit Backslashes maskieren, aber das Anführen der gesamten URL ist einfacher und weniger fehleranfällig. Enthält Ihre URL auch einfache Anführungszeichen, verwenden Sie stattdessen doppelte Anführungszeichen und maskieren Sie eingebettete Dollarzeichen oder Backticks.
Warum werden chinesische Zeichen in URLs zu Zeichenketten wie %E4%B8%AD?
Chinesische Zeichen werden zunächst in UTF-8-Bytes umgewandelt, dann wird jedes Byte als %XX prozentkodiert. Das Zeichen 中 (U+4E2D) wird zu drei UTF-8-Bytes (E4, B8, AD) und ergibt %E4%B8%AD — deshalb expandiert ein einziges chinesisches Zeichen auf 9 Zeichen in einer URL. Dieser dreistufige Prozess — Zeichen zu Unicode-Codepunkt, Codepunkt zu UTF-8-Bytes, Bytes zu prozentkodiertem Hex — gilt für alle Nicht-ASCII-Zeichen. Emoji benötigen oft 4 UTF-8-Bytes und expandieren daher auf 12 Zeichen bei der Prozentkodierung. Beim Dekodieren der URL geschieht das Umgekehrte: Die Hexwerte werden zurück in Bytes umgewandelt, die Bytes als UTF-8 interpretiert und die ursprünglichen Zeichen wiederhergestellt.
Sollte ich den OAuth-Parameter redirect_uri kodieren?
Ja, kodieren Sie ihn immer mit encodeURIComponent(). Die redirect_uri ist eine vollständige URL, die als Query-Parameter-Wert eingebettet ist, sodass ihre Sonderzeichen (?, &, =) kodiert werden müssen, damit sie nicht als Teil der äußeren URL-Struktur fehlinterpretiert werden. Beispiel: redirect_uri=https://myapp.com/callback?code=abc&state=xyz ohne Kodierung würde dazu führen, dass der Autorisierungsserver redirect_uri nur als https://myapp.com/callback?code=abc sieht, während state=xyz als separater Parameter der äußeren URL interpretiert würde. Die korrekt kodierte Version lautet redirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback%3Fcode%3Dabc%26state%3Dxyz.
Was ist der Unterschied zwischen Node.js querystring und URLSearchParams?
Verwenden Sie URLSearchParams für neue Projekte — es ist der WHATWG-Standard, entspricht dem Browserverhalten und funktioniert in Node.js und Browsern identisch. Das querystring-Modul ist veraltet und wird nicht mehr aktiv weiterentwickelt. Wesentliche Unterschiede: URLSearchParams kodiert Leerzeichen als + (Formularkodierungsstandard), verarbeitet mehrfache Schlüssel über getAll() und bietet eine iterierbare Schnittstelle mit entries()-, keys()- und values()-Methoden. Das querystring-Modul kodiert Leerzeichen als %20 und hat Eigenheiten bei der Array-Verarbeitung (key=1&key=2 wird zu { key: ['1', '2'] }). URLSearchParams ist standardkonform und wird von der Node.js-Dokumentation selbst empfohlen.
Wie kodiere ich eine URL in Python, JavaScript und Java?
JavaScript: encodeURIComponent('hello world') ergibt 'hello%20world'. Python: urllib.parse.quote('hello world') ergibt 'hello%20world'. Java: URLEncoder.encode('hello world', StandardCharsets.UTF_8) ergibt 'hello+world' (ersetzen Sie + durch %20 für RFC 3986). In JavaScript verwenden Sie encodeURIComponent() für Parameterwerte und encodeURI() für vollständige URLs. In Python 3 verwenden Sie urllib.parse.quote() für Pfadsegmente und urllib.parse.urlencode() für Query-Parameter — urlencode({'q': 'hello world'}) ergibt 'q=hello+world'. In Java verwendet URLEncoder die Formularkodierung (Leerzeichen als +). Für den Aufbau vollständiger URIs verwenden Sie java.net.URI oder die URIBuilder-Klasse von Apache HttpClient.
Welche Zeichen werden bei der URL-Kodierung nicht kodiert?
RFC 3986 definiert 66 nicht reservierte Zeichen, die niemals kodiert werden müssen: A-Z, a-z, 0-9, Bindestrich (-), Punkt (.), Unterstrich (_) und Tilde (~). Diese dürfen in jedem Teil einer URL buchstäblich erscheinen. Reservierte Zeichen — :, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ; und = — sind in ihrer strukturellen Funktion erlaubt (wie ? für Query-Strings), müssen aber prozentkodiert werden, wenn sie als buchstäbliche Daten verwendet werden. In JavaScript kodiert encodeURIComponent() alles außer A-Z a-z 0-9 - _ . ~ und ! ' ( ) *, während encodeURI() zusätzlich reservierte Zeichen bewahrt, die als URL-Trennzeichen dienen.
Was ist der Unterschied zwischen + und %20 bei der Kodierung von Leerzeichen?
Beide stehen für ein Leerzeichen, aber %20 ist die universell sichere Wahl. Die +-Konvention stammt aus der HTML-Formularkodierung (application/x-www-form-urlencoded) und funktioniert nur in Query-Strings. In URL-Pfadsegmenten ist + ein buchstäbliches Pluszeichen, kein Leerzeichen. Verwenden Sie im Zweifelsfall %20. Die +-Kodierung stammt aus der HTML-Spezifikation — wenn Browser Formulare absenden, werden Leerzeichen zu + und das +-Zeichen selbst zu %2B. Die %20-Kodierung stammt aus RFC 3986 (URI-Syntax), wo jedes nicht reservierte Zeichen als Prozentzeichen gefolgt von zwei Hexadezimalziffern kodiert wird. %20 funktioniert in allen Teilen einer URL: Pfad, Query und Fragment.
Wie behandelt die URL-Kodierung Emoji?
Ein einzelnes Emoji expandiert in einer URL typischerweise auf 12 Zeichen. Emoji werden in UTF-8-Bytes umgewandelt (in der Regel 4 Bytes), dann wird jedes Byte als %XX prozentkodiert. Zum Beispiel wird 🚀 (U+1F680) zu %F0%9F%9A%80. Die meisten Emoji verwenden Codepunkte im Bereich U+1F000 bis U+1FFFF oder höher, die 4 Bytes in UTF-8 benötigen. Einige Emoji mit Hautton-Modifikatoren oder ZWJ-Sequenzen bestehen aus mehreren Codepunkten und können bei der Kodierung auf über 30 Zeichen expandieren. Trotz dieser Expansion ist die Kodierung vollständig umkehrbar — die Dekodierung von %F0%9F%9A%80 ergibt korrekt 🚀.
Kann URL-Kodierung zur Verschlüsselung oder Sicherheit verwendet werden?
Nein. URL-Kodierung ist keine Verschlüsselung und bietet keinerlei Sicherheit. Es handelt sich um eine vollständig umkehrbare, deterministische Transformation — jeder kann eine prozentkodierte Zeichenkette sofort ohne Schlüssel oder Geheimnis dekodieren. Sie dient ausschließlich der Maskierung von Sonderzeichen für den sicheren URL-Transport. URL-Kodierung als Verschleierung oder Sicherheitsmaßnahme zu betrachten, ist ein gefährlicher Irrtum. Sensible Daten wie Passwörter, Token oder persönliche Informationen sollten durch HTTPS (TLS-Verschlüsselung der gesamten Anfrage) geschützt werden, nicht durch URL-Kodierung. Außerdem erscheinen URLs häufig in Server-Logs, dem Browserverlauf und Referrer-Headern, weshalb sensible Daten grundsätzlich im Anfrage-Body statt in der URL übertragen werden sollten.
Wie lang darf eine URL maximal sein?
Es gibt kein offizielles Maximum, aber halten Sie URLs für maximale Kompatibilität unter 2.000 Zeichen. Die meisten Browser unterstützen etwa 2.048 Zeichen, Apache ist standardmäßig auf 8.190 Bytes und Nginx auf 8.192 Bytes begrenzt. Verwenden Sie bei großen Datenmengen stattdessen POST-Anfragen. Die HTTP-Spezifikationen (RFC 7230) definieren keine maximale URL-Länge, aber auf jeder Ebene bestehen praktische Grenzen. Chrome und Firefox können URLs mit über 100.000 Zeichen verarbeiten, während IIS Query-Strings auf 16.384 Bytes begrenzt. CDNs und Proxys haben möglicherweise noch strengere Limits. Wenn URL-Kodierung Zeichen expandiert — insbesondere Nicht-ASCII-Text — kann eine scheinbar kurze URL diese Grenzen schnell erreichen.
Was ist der Unterschied zwischen einer URL und einer URI?
Eine URI (Uniform Resource Identifier) ist jede Zeichenkette, die eine Ressource identifiziert. Eine URL (Uniform Resource Locator) ist eine URI, die zusätzlich angibt, wie man über ein Protokoll wie https:// darauf zugreift. Alle URLs sind URIs, aber nicht alle URIs sind URLs — beispielsweise identifiziert ein URN wie urn:isbn:0451450523 ein Buch über die ISBN, sagt aber nicht, wo man es findet. In der alltäglichen Webentwicklung werden die Begriffe URL und URI oft synonym verwendet. Die in RFC 3986 definierten Kodierungsregeln gelten für beide. Die JavaScript-Funktionen heißen encodeURI/decodeURI und verwenden die allgemeinere URI-Terminologie, obwohl die meisten Entwickler ausschließlich mit URLs arbeiten.

Verwandte Werkzeuge

Alle Werkzeuge anzeigen →

Base64-Dekodierer & -Kodierer

Kodierung & Formatierung

Base64 online kostenlos dekodieren und kodieren. Echtzeitkonvertierung mit voller UTF-8- und Emoji-Unterstützung. 100 % privat — läuft in Ihrem Browser. Keine Anmeldung nötig.

JSON-Formatierer & Validator

Kodierung & Formatierung

JSON sofort im Browser formatieren, validieren und verschönern. Kostenloses Online-Tool mit Syntaxprüfung, Fehlererkennung, Minifizierung und Ein-Klick-Kopie. 100 % privat.

Zahlensystem-Konverter — Binär, Hex, Dezimal & Oktal

Konvertierungswerkzeuge

Zahlen zwischen Binär, Hexadezimal, Dezimal, Oktal und beliebigen Basen (2–36) sofort konvertieren. Kostenlos, privat, ohne Anmeldung — alles läuft in Ihrem Browser.

Bilder Online Komprimieren — JPEG, PNG & WebP

Konvertierungswerkzeuge

Bildgröße um bis zu 80 % reduzieren — JPEG, PNG & WebP im Browser komprimieren, kein Upload nötig. Stapelverarbeitung für 20 Bilder, Qualität anpassen, Vorher-Nachher vergleichen. Kostenlos & privat.

Längeneinheiten-Umrechner — Metrisch, Imperial & mehr

Konvertierungswerkzeuge

1 Zoll = 2,54 cm, 1 Fuß = 0,3048 m, 1 Meile = 1,609 km. Zwischen 16 Längeneinheiten sofort umrechnen — metrisch, imperial, nautisch & astronomisch. Kostenlos, privat, läuft im Browser.

MD5-Hash-Generator & Datei-Prüfsummen-Tool

Sicherheitswerkzeuge

MD5-, SHA-256-, SHA-1- & SHA-512-Hashes online kostenlos generieren. Text oder Dateien im Browser hashen, Prüfsummen verifizieren und Ergebnisse kopieren. Ohne Anmeldung.