URL-Encoder/Decoder

• Base64-Encoder/Decoder
• Base64-Encoder
• Base64-Decoder
• Alle Konverter

Browser, Server und Caches interpretieren bestimmte Zeichen als Struktur — Leerzeichen, kaufmännische Unds, Doppelkreuze und Nicht-ASCII-Text müssen escaped werden, wenn sie Daten statt Syntax sind. Das Tool zeigt die exakte Zeichenkette, die ein HTTP-Client sendet.

Vorteile korrekter URL-Kodierung

• Sichere Übertragung: Reservierte Zeichen in Nutzerinhalten brechen Parser für Pfade, Queries und Fragmente nicht mehr.
• Unicode-Unterstützung: UTF‑8-Bytes lassen sich als %-Sequenzen darstellen, damit internationaler Text reine-ASCII-Transporte übersteht.
• Vorhersehbare APIs: Angleichung an RFC 3986 reduziert Abweichungen zwischen Frontend, Apps und Backend-Frameworks.
• Weniger 400-Fehler: Richtig kodierte Parameter werden seltener von strikten Gateways abgewiesen.
• Einfacheres Debugging: Vergleichen Sie Ihre manuelle Zeichenkette mit encodeURIComponent, bevor Sie einen Hotfix ausliefern.

Percent-Encoding schreibt jedes Byte, das nicht wörtlich in einem URL-Segment stehen darf, als %HH mit hexadezimal HH. Welche Zeichen wörtlich bleiben, hängt davon ab, ob eine ganze URL oder ein einzelnes Teil geschützt wird.

Modi dieses Tools

• Komponentenmodus: Entspricht encodeURIComponent / decodeURIComponent — ideal für Schlüssel, Werte, Pfadsegmente oder Text für Query-Strings.
• Voll-URL-Modus: Entspricht encodeURI / decodeURI — für Zeichenketten, die nach der Transformation weiter Schema, Host, Schrägstriche und Query-Zeichen enthalten.
• Live-Transformation: Jede Änderung läuft über das gewählte Paar, damit fehlerhafte Eingaben oder Doppelkodierung sofort sichtbar werden.

Kleinigkeiten — z. B. Pluszeichen in Formularposts versus echtes Percent-Encoding — verwirren Teams, wenn Frameworks unterschiedlich vorgehen.

Kurzreferenz

• Leerzeichen ist in Queries oft %20; HTML-Formulare können + in application/x-www-form-urlencoded-Bodys nutzen.
• Nur unreservierte Zeichen (Buchstaben, Ziffern, -._~) dürfen im strikten Komponentenmodus unverschlüsselt bleiben.
• Doppelkodierung (bereits kodierte Zeichen erneut kodieren) verlängert URLs und kann Server verwirren.
• decodeURIComponent wirft bei % mit unvollständigem Hex; Quelle zuerst korrigieren.
• Internationalisierte Domains nutzen Punycode im DNS; URL-Kodierung betrifft Pfad und Query, nicht die ACE-Hostnamenkonvertierung.

Empfehlungen

Kodieren Sie an der Grenze, wo nicht vertrauenswürdiger Text Teil einer URL wird, und dekodieren Sie einmal, wenn Sie ihn wieder als Daten behandeln.

• Kodieren Sie jeden Abfragewert einzeln statt die ganze URL zweimal zu kodieren.
• Protokollieren Sie Roh-Eingabe getrennt von der kodierten Zeichenkette bei Analytics- oder Redirect-Debugging.
• Bevorzugen Sie HTTPS für kodierte URLs mit sensiblen Tokens.
• Validieren Sie dekodierte Ausgabe vor HTML-Einbindung gegen XSS durch bösartige Links.
• Testen Sie beide Modi bei Deep Links aus E-Mail- oder SMS-Vorlagen.

Einsatzszenarien

• Webentwicklung: Suchfilter, UTM-Parameter und OAuth-Redirect-URIs zuverlässig bauen.
• API-Integration: Verhalten wie in Dokumentationen mit RFC-3986-Percent-Encoding.
• QA und Support: Kunden-URLs nachstellen ohne zu raten, welche Zeichen escaped wurden.
• Dokumentation: Exakte Vorher/Nachher-Beispiele für Partnerintegrationen.
• Migrationsskripte: Alte Escape-Regeln mit modernen Browserfunktionen vergleichen.