🚀 Schnellstart

Geben Sie oben den Inhalt ein (URL, Text, CJK usw)
Zum Moduswechsel auf Kodieren oder Dekodieren klicken
Per Schaltfläche starten; das Ergebnis erscheint im selben Textfeld
Verwenden Sie die Kopieren‑Schaltfläche unten

📌 Häufige Anwendungsfälle

API‑Parameter: Query‑Parameter und Request‑Bodies kodieren, damit Sonderzeichen korrekt übertragen werden
Formularübermittlung: GET/POST‑Daten behandeln; CJK und Sonderzeichen werden unterstützt
Freigabelinks: URLs mit CJK/Sonderzeichen ohne Zeichenfehler erzeugen
Suchanfragen: Schlüsselwörter kodieren, besonders bei & = # ?

🧭 Anwendungstipps

Doppelte Kodierung vermeiden: prüfen, ob bereits %XX‑Sequenzen enthalten sind
Teilweise kodieren: nur Parameterwerte kodieren (z. B. ?key=kodiert), URL‑Struktur beibehalten
Debugging: Parameter in Netzwerkanfragen dekodieren, um Probleme schnell zu finden
Reservierte Zeichen: : / ? # [ ] @ ! $ & ' ( ) * + , ; = haben besondere Bedeutung; als Daten meist zu kodieren (kontextabhängig, v. a. : / ? # & = +)
Zeichenkodierung: Nicht‑ASCII‑Zeichen werden als UTF‑8 (1–4 Bytes) kodiert; jedes Byte als %HH

⚠️ Einschränkungen & Kompatibilität

URL‑Kodierung ≠ Verschlüsselung: eine reversible Formatumwandlung, die keine sensiblen Daten schützt
URL‑Länge: empfohlene Gesamtlänge < 2048 Zeichen (je nach Browser/Server)
Leerzeichen: in Query‑Strings + (Formkodierung) oder %20 (allgemein); dieses Tool nutzt standardmäßig %20
Sehr langer Text: kann den Browser unresponsiv machen oder zum Absturz bringen; nach Abschnitten verarbeiten

🔒 Datenschutz & Sicherheit

Die gesamte Verarbeitung erfolgt in Ihrem Browser; Daten verlassen Ihr Gerät nicht
Sensible Daten (Passwörter, Schlüssel, Tokens) verschlüsseln statt kodieren

❓ FAQ

Was ist eine URL und warum wird sie „kodiert“?

Die URL (Uniform Resource Locator) wurde in den 1990er‑Jahren von Tim Berners‑Lee für das Web eingeführt: eine lesbare Zeichenkette, die Scheme/Host/Path/Query/Fragment beschreibt. Damit Datenzeichen nicht als Trenner (? & # = /) fehlgedeutet werden und um Leerzeichen, Nicht‑ASCII und Emoji zu behandeln, werden sie per Percent‑Encoding %HH umgeschrieben (z. B. Leerzeichen→%20; „/“ in Parameterwerten→%2F). Im Kontext von application/x‑www‑form‑urlencoded kann ein Leerzeichen auch als „+“ notiert werden (außerhalb von Formularen wird %20 empfohlen). URL‑Kodierung ist eine reversible Formatierung zur Robustheit von Links; sie bietet weder Verschlüsselung noch Vertraulichkeit.

Schützt Kodierung sensible Informationen?

Nein. Kodierung ist eine umkehrbare Formatumwandlung. Passwörter, API‑Keys usw. müssen verschlüsselt werden

Warum ist ein Leerzeichen mal + und mal %20?

Formulare (application/x-www-form-urlencoded) verwenden +, während RFC 3986 allgemein %20 vorsieht. Dieses Tool nutzt %20 für bessere Kompatibilität; + nur im Formular‑Kontext oder manuell verwenden

Woran erkenne ich, ob Inhalte bereits kodiert sind?

Kodierte Inhalte enthalten %XX‑Sequenzen (% gefolgt von zwei Hex‑Ziffern, z. B. %E4%BD%A0). Bei vielen solchen Sequenzen: bereits kodiert; nicht erneut kodieren

Warum müssen Nicht‑ASCII‑Zeichen kodiert werden?

Der URL‑Standard erlaubt nur ASCII. Nicht‑ASCII‑Text (z. B. Akzentzeichen, Emoji) muss als Prozentkodierung übertragen werden (UTF‑8‑Bytes als %HH)

Müssen Schrägstriche / kodiert werden?

Kommt auf die Position an: als Pfadtrenner nicht kodieren (z. B. /api/users). Als Parameterwert zu %2F kodieren (z. B. ?path=%2Fhome%2Fuser)