URL-Encoder/Decoder

URI-Komponenten und vollständige URLs codieren und decodieren

So funktioniert es

URL-Encoder/Decoder — URI-Komponenten und vollständige URLs codieren und decodieren. Alle Verarbeitung erfolgt in deinem Browser — kein Upload, keine Anmeldung, keine E-Mail. Für immer kostenlos.

Zuletzt aktualisiert: 2026-05-06

Editor's note

Wir sehen denselben Bug in Code-Reviews immer wieder — encodeURI gegen encodeURIComponent — und er taucht fast immer um 2 Uhr nachts auf, wenn ein Webhook-Query-String mit einem "+" in einer E-Mail-Adresse still aufgefressen wird und der Reset-Link einer Kundin auf das falsche Postfach zeigt. Die beiden Funktionen sehen austauschbar aus, bis du die Spec liest, und die meisten lesen die Spec erst nach dem Postmortem. Deshalb stellen wir beide Modi nebeneinander: Die Antwort auf "hast du das für den richtigen Scope escaped" hört auf, eine Raterei am Keyboard zu sein.

Wir weigern uns außerdem, deine URL irgendwohin zu schicken. Die Hälfte der Zeit ist der String in der Box ein signierter Callback oder ein Einmal-Token, der außerhalb deines Laptops nicht existieren sollte. Encoding ist lokales JavaScript — kein fetch, keine Telemetrie, kein cleveres "Share Link"-Feature, das deinen Input still spiegelt. Wenn wir schon die Textarea hosten, in die deine Produktions-Secrets eingefügt werden, ist das Mindeste, dass nichts die Seite verlässt.

Über URL-Encoder/Decoder

URLs dürfen nur eine kleine Teilmenge der ASCII-Zeichen sicher transportieren. Sobald du ein Leerzeichen, einen Schrägstrich, ein Emoji, ein deutsches "ß" oder einen Query-Wert mit "&" in einen Link packen willst, musst du percent-encoden. Dieser URL Encoder/Decoder verwendet exakt dieselben Algorithmen, die der Browser intern nutzt — encodeURI für ganze URLs und encodeURIComponent für einzelne Query-String-Werte — sodass die Ausgabe byteweise identisch mit dem ist, was dein Code produziert.

Nutze ihn, wenn du einen OAuth-Redirect baust, eine doppelt kodierte Webhook-URL debuggst, einen Tracking-Link mit UTM-Parametern und Leerzeichen erstellst oder einen nicht-ASCII-Pfad in Slack einfügst und nur eine Wand aus "%C3%BC" zurückbekommst. Der Moduswechsel zeigt, wie reservierte Zeichen wie "/", "?" und "&" zwischen Full-URL- und Component-Kontext unterschiedlich behandelt werden — und genau dort verstecken sich die meisten Encoding-Bugs.

Alles passiert in deinem Browser. Nichts an der URL — weder Tokens noch Session-IDs oder PII im Query-String — wird an einen Server gesendet, geloggt oder gecached. Das ist wichtig, wenn du einen Produktions-Link mit einem signierten Einmal-Parameter debuggst, den du nicht leaken willst.

So verwenden Sie URL-Encoder/Decoder

Füge deine URL oder den Roh-Text in das Eingabefeld ein.
Wähle einen Modus: encodeURIComponent für Query-Parameter-Werte oder encodeURI (vollständige URL) für komplette Links.
Klicke auf Encode, um Roh-Zeichen in Percent-Escapes zu wandeln, oder auf Decode, um einen kodierten String umzukehren.
Kopiere das Ergebnis mit einem Klick und füge es in deinen Code, Browser oder Postman-Request ein.
Wenn beim Decoden "Invalid encoded sequence" erscheint, prüfe das Input auf einzelne "%"-Zeichen ohne zwei folgende Hex-Ziffern.

Häufige Anwendungsfälle

OAuth-/SAML-Redirect-URLs bauen, bei denen state und code unverändert ankommen müssen.
Nicht-ASCII-Dateinamen kodieren, bevor sie in Content-Disposition-Header oder S3-Keys landen.
Doppelt kodierte URLs ("%2520" statt "%20") aus einem fehlkonfigurierten Proxy bereinigen.
Sichere Query-String-Werte für Tracking-Links mit Leerzeichen, Ampersands oder Anführungszeichen erzeugen.
Webhook-Payloads debuggen, bei denen ein Service einen Wert URL-kodiert und der nächste ihn doppelt dekodiert hat.

Tipps und häufige Fehler

Verwende encodeURIComponent für jeden einzelnen Wert nach "=" im Query-String. encodeURI ist nur für die ganze URL gedacht — es lässt "&", "=", "?" und "/" absichtlich unangetastet.
Leerzeichen im Query-String sollten zu "%20" werden, nicht zu "+". Die "+"-Form gilt nur für application/x-www-form-urlencoded-Bodies, nicht für URL-Pfade.
Wenn ein String nach Encode → Decode mit zusätzlichen Escapes zurückkommt, war dein Input bereits einmal kodiert — erst dekodieren, dann neu kodieren.
Hash-Fragmente ("#abschnitt") bleiben bei encodeURI erhalten, werden aber von encodeURIComponent als Literal-Text behandelt — wähle den passenden Modus.

Häufig gestellte Fragen

Unterschied zwischen encodeURI und encodeURIComponent?

encodeURI behält strukturelle URL-Zeichen wie /, ?, & — für vollständige URLs. encodeURIComponent kodiert auch diese — für Query-Parameter-Werte etc.

Warum 'Ungültige kodierte Sequenz' beim Dekodieren?

Die Eingabe enthält eine fehlerhafte %-Escape (z.B. '%G1'). Stelle sicher, dass jedem % zwei gültige Hex-Ziffern folgen, oder verwende erst 'Encode' auf reinem Text.

Werden meine Daten irgendwohin gesendet?

Nein. Encoding/Decoding läuft lokal im Browser — nichts wird hochgeladen oder protokolliert.

Verarbeitet das Tool Nicht-ASCII-Zeichen wie deutsche Umlaute oder Emojis?

Ja. Der Input wird vor dem Percent-Encoding als UTF-8 interpretiert, sodass "ü" zu "%C3%BC" wird und ein einzelnes Emoji zu einer Vier-Byte-Sequenz — exakt nach RFC 3986 und genauso wie fetch() im Browser.

Kann ich eine ganze URL inklusive Query-String auf einen Schlag kodieren?

Mit dem Modus "encodeURI (vollständige URL)" bleiben strukturelle Zeichen wie /, ?, #, &, = intakt, alles andere wird escaped. Wenn du einen einzelnen Parameter-Wert (z. B. eine in einer URL verschachtelte Redirect-URL) kodieren musst, wechsle für dieses Stück auf encodeURIComponent.

Warum wird "+" mal zu "%2B" und bleibt mal als "+" erhalten?

In einem URL-Pfad oder Query-Wert via encodeURIComponent ist "+" reserviert und wird zu "%2B". Im encodeURI-Modus gilt es als sicher und bleibt unverändert. Der häufigste Bug entsteht beim Mischen — eine E-Mail wie "name+tag@example.com" wird dann als Leerzeichen interpretiert.