Tool-Hinweise

Über URL-Kodierer/Dekodierer

Ein URL Encoder/Decoder wandelt unsichere oder reservierte URL-Zeichen in percent-encoded Text um und decodiert codierte Strings zurück in lesbaren Text.

Er hilft bei Query-Parametern, nicht-englischen Pfaden, Callback-URLs und URL-Fragmenten aus Logs. Alles läuft lokal im Browser.

So nutzen Sie URL Encoder/Decoder

Fügen Sie eine komplette URL, einen Query-Parameter-Wert oder den zu codierenden Text ein.
Klicken Sie Encode, um Leerzeichen, nicht-englischen Text und Symbole in sicheres Percent Encoding zu wandeln.
Klicken Sie Decode, um Strings wie %E4%B8%AD%E6%96%87 wieder lesbar zu machen.
Wenn nur ein Parameter codiert werden muss, codieren Sie den Wert statt des ganzen Query Strings, damit & und = ihre Struktur behalten.

Typische Einsatzfälle

Suchbegriffe, Callback-URLs oder Redirect-Parameter vor dem Einfügen in eine URL codieren, damit &, ? und # den Parameter nicht abbrechen.
Percent-encoded Paths oder Query Strings aus API-Logs lesbar decodieren.
Double-Encoding-Probleme in OAuth redirect_uri, Webhook-Callbacks oder Share-Links debuggen.
Frontend encodeURIComponent-Ausgabe mit dem vergleichen, was das Backend erhält.

Percent Encoding, Query-Parameter und typische Fallen

Einige URL-Zeichen haben strukturelle Bedeutung, etwa ?, &, =, # und /. Percent Encoding schreibt Bytes als %HH, damit diese Zeichen als Daten übertragen und nicht als URL-Struktur gelesen werden.

Leerzeichen: meist %20; in Form Encoding kann auch + erscheinen.
Nicht-englischer Text und Emoji: werden zuerst als UTF-8-Bytes codiert und dann als Percent-Sequenzen geschrieben.
encodeURI vs encodeURIComponent: encodeURI erhält Strukturzeichen; encodeURIComponent ist besser für einzelne Parameterwerte.
Double Encoding: %25E4 bedeutet oft, dass ein vorhandenes Prozentzeichen erneut codiert wurde.

Häufige Fragen zu URL-Kodierer/Dekodierer

Soll ich eine ganze URL oder einen Parameter codieren?: Meist codieren Sie einen Parameterwert. Eine ganze URL zu codieren escaped auch : / ? & und kann den Link falsch parsebar machen.
Warum ist ein Leerzeichen manchmal %20 und manchmal +?: %20 ist allgemeines Percent Encoding. Das Pluszeichen ist in application/x-www-form-urlencoded üblich.
Warum bleiben nach dem Decoding Prozentzeichen?: Der Text kann doppelt codiert sein, oder der Originalwert enthält ein echtes Prozentzeichen. Decodieren Sie erneut nur bei sicherem Double Encoding.
Braucht URL-safe Base64 noch URL Encoding?: Oft weniger, weil + und / vermieden werden. Prüfen Sie trotzdem = Padding oder Sonderzeichen vor Query Strings.
Wird meine Eingabe hochgeladen?: Nein. Encoding und Decoding laufen lokal im Browser und werden nicht an wetool.site gesendet.

URL Encoding vs Base64

URL Encoding macht Zeichen innerhalb von URLs sicher. Base64 stellt Bytes als Text dar. Tokens, Bilder und binäre Payloads können beides enthalten, aber für verschiedene Zwecke.

encodeURI vs encodeURIComponent

Viele URL-Encoding-Fehler entstehen, wenn eine vollständige URL und ein einzelner Parameterwert gleich behandelt werden.

Vollständige URL: encodeURI-Semantik behält : / ? & = # als Strukturzeichen und passt zu bereits zusammengesetzten Links.
Parameterwert: encodeURIComponent-Semantik kodiert &, =, ? und # und passt zu search, redirect_uri, callback und ähnlichen Werten.
Formularregeln: application/x-www-form-urlencoded schreibt Leerzeichen oft als +; allgemeines Percent-Encoding nutzt meist %20.

URL-Encoding Debugging-Checkliste

Wenn das Backend falsche URL-Parameter erhält, prüfen Sie, wie oft Browser, Frontend-Code, Gateway und Backend-Framework kodieren oder dekodieren.

%25 bedeutet oft, dass ein vorhandenes Prozentzeichen erneut kodiert wurde; double encoding ist wahrscheinlich.
Wenn redirect_uri eine eigene Query enthält, müssen innere ?, & und = als Daten kodiert werden.
Setzen Sie dekodierte Nutzereingaben nicht direkt in HTML oder Redirect-URLs ein; nutzen Sie weiter Protokoll-Allowlist und Output-Escaping.