Prozentcodiert

Decodierter Text

Was ist der URL-Decoder?

Füge einen prozentcodierten String in das linke Panel ein, und das rechte Panel zeigt das Original. Unter der Haube läuft decodeURIComponent, das jede %XX-Sequenz im Input durchgeht, diese Hex-Paare als UTF-8-Bytes behandelt und die Originalzeichen rekonstruiert. So wird %20 zu einem Leerzeichen, %26 zu &, %E2%9C%85 zu einem Häkchen. Die umgekehrte Richtung lebt im URL-Encoder.

Warum ist Decodieren tückisch? Weil nicht jedes % in freier Wildbahn Teil einer gültigen prozentcodierten Sequenz ist. Ein einzelnes % gefolgt von Nicht-Hex-Zeichen (%G1, % am Stringende) ist fehlerhaft, und der Decoder wirft einen URIError: URI malformed. Diese Seite fängt das ab und zeigt eine freundliche "Ungültige Codierung"-Meldung statt eines Stack-Traces, sodass ein kaputter Paste die Seite nicht zerlegt. Die genauen Regeln, was als gültig zählt, leben in RFC 3986 §2.1 und im WHATWG URL Standard.

Achtung vor Doppelcodierung. Wenn du einen String decodierst und der Output IMMER NOCH %-Zeichen enthält (z. B. du bekommst Ava%2520Chen statt Ava Chen zurück), wurde der Wert irgendwo in der Kette zweimal codiert — meist ein Proxy oder Framework, das einen bereits codierten Wert automatisch nochmal codiert hat. Nochmal decodieren bringt dich den Rest des Wegs. Wikipedias Notizen zur Doppelcodierung haben eine gute Erklärung, wie das passiert. Alles läuft in deinem Browser. Kein Upload, kein Server, keine Logs.

So benutzt du den URL-Decoder

Drei Schritte. Die Seite aktualisiert sich beim Tippen — kein Convert-Button.

Codierten String einfügen oder Beispiel klicken

Wirf einen prozentcodierten String ins linke Panel. Klick auf Beispiel, um ein realistisches Beispiel zu laden. Beispieleingabe:

Ava%20Chen%20%26%20friends%3F%20customer%40shop.com%20%20100%25%20off!

Fehlerhafte Eingabe (ein einzelnes <code>%</code>, ein ungültiges Hex-Paar wie <code>%G1</code>) erscheint im Output-Panel als "Ungültige Codierung"-Meldung — siehe die <a href="https://tc39.es/ecma262/#sec-decodeuricomponent-encodeduricomponent" target="_blank" rel="noopener">ECMAScript-Spec für decodeURIComponent</a> für die genauen Fehlerregeln.

Den decodierten Output lesen

Das rechte Panel zeigt den decodierten Text. %20 wird zu Leerzeichen, %26 zu &, %3F zu ?, %40 zu @, %25 zu %. Aktualisiert sich beim Tippen.

Kopieren oder herunterladen

Klick Kopieren, um den decodierten Text in deine Zwischenablage zu legen, oder Herunterladen, um ihn als .txt-Datei zu speichern. Mit Leeren auf dem Input-Panel fängst du neu an. Andersrum geht es im URL-Encoder.

Wann du das wirklich brauchst

Lesen, was wirklich in einem Query-Parameter steht

Eine URL wie ?customer=Ava%20Chen&tag%5B0%5D=red lässt sich mit den Prozent-Codes drin schwer überfliegen. Füg einen einzelnen Wert hier ein und du bekommst Ava Chen oder tag[0] zurück — sofort offensichtlich, ob der Parameter ist, was du erwartest. Um eine ganze URL zu zerlegen, übernimmt der URL-Parser Query-Parameter automatisch.

Doppelt codierte Werte debuggen

Du fügst Ava%2520Chen ein, decodierst einmal, bekommst Ava%20Chen. Diese Extra-Schicht ist der Beweis — irgendwo hat ein Proxy, Framework oder eine Library den Wert ein zweites Mal codiert. Nochmal decodieren liefert den echten String. OAuth-Specs sind häufige Schuldige, weil redirect_uri-Werte oft durch Schichten laufen, die jeweils hilfsbereit nochmal codieren.

Webhook- und Analytics-URLs aus Logs untersuchen

Wenn in der Produktion etwas schiefläuft, ist die URL im Access-Log meist komplett codiert — %7B%22event%22%3A%22signup%22%7D statt des JSONs, das der Webhook tatsächlich gesendet hat. Hier einfügen und du bekommst {"event":"signup"} zurück, was tatsächlich lesbar ist.

Magic-Link oder Passwort-Reset-URL decodieren

Wenn ein Kunde wie Marco Rivera sagt "der Reset-Link ist kaputt", enthält der Link einen Token, eine E-Mail und ein Redirect-Ziel — alles prozentcodiert. Den verdächtigen Parameter zu decodieren zeigt, ob die E-Mail die richtige Adresse ist, ob der Token den Mail-Client überlebt hat oder ob der Redirect-URI abgeschnitten wurde.

Häufige Fragen

Was passiert bei fehlerhafter Eingabe wie einem einzelnen % oder %G1?

Das native decodeURIComponent wirft einen URIError: URI malformed bei einer Sequenz, die kein gültiges %XX-Hex-Paar ist. Diese Seite fängt das ab und schreibt "Ungültige Codierung: ..." ins Output-Panel statt zu crashen. Die häufigsten Ursachen sind ein verirrtes literales %, das eigentlich %25 hätte sein sollen, oder ein Copy-Paste, bei dem ein nachgestellter Hex-Digit verloren ging.

Woran erkenne ich, dass meine Eingabe doppelt codiert ist?

Einmal decodieren. Wenn der Output noch %-Zeichen enthält (besonders %20, %2F, %3A) und eigentlich Klartext sein sollte, wurde er zweimal codiert. Den Output der ersten Decodierung nochmal decodieren. Drei Runden sind selten, aber möglich — meist heißt das, dass eine Kette aus drei verschiedenen Services denselben Wert jeweils codiert hat.

Was ist mit Plus-Zeichen — sollten die zu Leerzeichen werden?

Nicht mit decodeURIComponent — das lässt + in Ruhe. Die +-als-Leerzeichen-Konvention gehört zu application/x-www-form-urlencoded (HTML-Formular-Submits), nicht zur allgemeinen URL-Prozentcodierung. Wenn deine Eingabe aus einem Formular-Body kommt und + für Leerzeichen hat, lauf erst .replace(/\+/g, "%20") drüber, dann decodieren. Die WHATWG-Spec für application/x-www-form-urlencoded beschreibt diese Zwei-Geschmacks-Situation.

Geht das mit Unicode und Emojis sauber im Round-Trip?

Ja. Prozentcodierte Multi-Byte-UTF-8-Sequenzen (z. B. %E2%9C%85 für ein Häkchen, %F0%9F%9A%80 für eine Rakete) decodieren direkt zurück zu den Originalzeichen. Das schlägt nur fehl, wenn der Encoder ein Nicht-UTF-8-Charset benutzt hat, was moderne Systeme nicht tun.

Wird die Eingabe, die ich hier einfüge, irgendwo hingeschickt?

Nein. Die Decodierung läuft komplett in deinem Browser. Kein Netzwerk-Call, kein Server-Log, nichts verlässt deine Maschine. Tokens, E-Mails, signierte URLs — alles sicher zum Einfügen.

Wie groß darf der String sein, den ich hier decodiere?

Es gibt eine 256-KB-Grenze für den Input. Wenn du hunderte KB prozentcodierten Text hast, hast du fast sicher ein Payload, das serverseitig decodiert werden sollte statt in ein Tool gepastet — codierte Payloads in dieser Größe deuten meist auf Missbrauch der URL-Codierung für einen Job hin, der nach Base64 oder einem Request-Body ruft.

Weitere URL- und Codierungs-Tools

Decodieren ist eine Operation. Hier ist, was sich natürlich damit kombiniert: