Zum Inhalt springen
Alle Tools

URL Encoder/Decoder

URLs und Query-Parameter prozentual kodieren oder dekodieren.

So funktioniert das Tool

URL-Encoding (Percent-Encoding, RFC 3986) ersetzt reservierte und nicht-ASCII-Zeichen in URLs durch ihre Prozent-Hex-Sequenz: Leerzeichen wird %20, ä wird %C3%A4, ein Schrägstrich in einem Query-Parameter wird %2F. Unser Encoder/Decoder ist UTF-8-korrekt - was beim Übergeben von Query-Parametern mit Sonderzeichen, beim Bauen von OAuth-Authorization-URLs oder beim Inspizieren von Trackern wichtig ist. Alles passiert via encodeURIComponent im Browser, kein Server-Roundtrip.

Typische Anwendungsfälle

Query-Parameter mit Sonderzeichen

Eine Such-URL mit Leerzeichen und Umlauten bauen, ohne dass der Server „kann den Parameter nicht parsen” zurückgibt.

OAuth-Redirect-URLs

Provider wie Threads, X, Google verlangen, dass die redirect_uri exakt percent-codiert übergeben wird - ein Doppel-Encoding bricht den Flow.

Tracking-Parameter dekodieren

Eine Marketing-URL hat utm_content=Mein%20Tool%20%E2%9C%85 - dekoden zeigt dir den lesbaren Text inklusive Emoji.

Bug-Reports mit URL-Beispielen

Wenn du eine URL in einem Markdown-Bugreport teilst, willst du sie roh haben - dekoden hilft beim Lesen, encoden beim sauberen Teilen.

FAQ

Häufige Fragen

Welche Encoding-Funktion nutzt das Tool?

encodeURIComponent für das Encoden - die kodiert alles außer A-Z, a-z, 0-9, -, _, ., ~ und ist die richtige Wahl für Query-Parameter-Werte. Für das Encoden ganzer URLs (mit Schema, Host, Pfad) bräuchtest du encodeURI; das wäre aber meist nicht, was du tatsächlich willst.

Was ist der Unterschied zwischen + und %20?

Beide stehen für ein Leerzeichen, aber + nur im application/x-www-form-urlencoded-Format (alte HTML-Forms), %20 in URL-Pfaden und Query-Strings nach RFC 3986. Moderne Server akzeptieren meist beides, aber wenn du selbst encodest, nimm %20 - das ist eindeutig.

Warum bekomme ich nach dem Dekodieren Mojibake (ä statt ä)?

Doppel-Encoding: der Original-String war schon UTF-8-percent-encoded und wurde nochmal als Latin-1 fehlinterpretiert. Decode ein zweites Mal, dann steht meist das ä korrekt da. Wenn nicht, war die Quell-URL kaputt encodiert.

Wird mein URL-Input gespeichert?

Nein. Das Tool nutzt encodeURIComponent / decodeURIComponent im Browser. Kein Server, keine Logs, keine Übermittlung - auch nicht für Analytics. Du kannst URLs mit Auth-Tokens oder PII bedenkenlos hier verarbeiten.

Was muss ich bei OAuth-redirect_uri beachten?

Die redirect_uri muss zwischen Provider-Settings und Authorization-URL byte-identisch sein. Wenn du sie als Parameter an /authorize anhängst, encode den kompletten Wert - auch das https://, den : und die Slashes. Provider sind hier oft pingelig.

Verwandte Tools

Alle Daten bleiben in deinem Browser. Kein Server, kein Tracking.