Kostenloser URL Encoder Decoder Online - Prozentkodierung

A Dieses Tool ist auf Effizienz ausgelegt! Sie können mehrere verschiedene URL-Pfadsegmente oder Abfrageparameterwerte (jeweils in einer neuen Zeile) in den Encoder einfügen. Es verarbeitet jede Zeile unabhängig voneinander und wandelt Sonderzeichen in ihr korrektes prozentkodiertes Format um. Das spart erhebliche Zeit beim Vorbereiten zahlreicher neuer URLs für Sitemaps, interne Links oder API-Aufrufe und stellt sicher, dass alle Links vom ersten Tag Ihres Starts an gültig und robust sind.

A Dieses Tool konzentriert sich auf die URL-Kodierung, nicht auf die Zeichenumwandlung. Es geht davon aus, dass Ihr Eingabetext bereits in einem Standardformat wie UTF-8 vorliegt. Wenn Sie Text in einer anderen Kodierung haben, müssen Sie ihn zuerst in UTF-8 konvertieren, bevor Sie diesen Encoder verwenden, um eine ordnungsgemäße Prozentkodierung zu gewährleisten. Stellen Sie sicher, dass Ihre Zeichenkette als UTF-8-Bytes dargestellt wird, bevor Sie sie hier eingeben.

A encodeURI ist für ganze URLs gedacht, nicht für einzelne Parameterwerte. Es behält Zeichen mit spezieller Bedeutung bei — wie ?, #, / und =. Verwende stattdessen encodeURIComponent, wenn du diese Zeichen kodieren willst. Beispiel: encodeURI lässt ? in Ruhe, encodeURIComponent macht daraus %3F. Wähle im Tool den richtigen Modus je nach URL-Teil.

A Browser normalisieren URLs oft automatisch. Gibst du etwa ein Leerzeichen in der Adressleiste ein, wird es zu %20 umgewandelt, manche Browser zeigen es aber wieder als Leerzeichen an. Unser Tool zeigt dir die rohe Prozentkodierung, die tatsächlich übers Netzwerk geht. Füge die Adresse aus deinem Browser in den Dekodierer ein, um die wahren Zeichen zu sehen. Diese Diskrepanz überrascht viele Entwickler.

A Die Systeme sind komplett verschieden. URL-Encoding wandelt Leerzeichen in %20 um, HTML-Entity-Encoding nutzt   oder   dafür. Wer das verwechselt, bekommt kaputte Links oder sieht Rohcode auf der Webseite. Dieses Tool ist nur für URL-Encoding gedacht. Wenn du in JSON-API-Antworten & statt & siehst, hast du ein HTML-Problem, kein URL-Problem.

A Doppelkodierung passiert, wenn jemand einen bereits kodierten String nochmal kodiert. Dann taucht %2520 statt %20 auf. Lauf es einmal durch den Dekodierer, prüf ob noch Prozentzeichen da sind, und dekodier bei Bedarf erneut. Drei Durchläufe sind so gut wie nie nötig. Wenn ein Zahlungs-Gateway-Callback wirr aussieht, ist das meist der Grund.

A Nein, überhaupt nicht. Die URL-Kodierung ist reine Formatierung – sie macht aus Leerzeichen %20 und aus Sonderzeichen Prozentcodes. Jeder kann das mit diesem Tool sofort wieder entschlüsseln. Stell dir vor, du wickelst ein Sandwich in Klarsichtfolie: ordentlich, aber völlig durchsichtig. Wenn du Passwörter oder API-Schlüssel über URLs teilst, nutze echte Verschlüsselung oder Hashes. Kodieren allein bringt null Sicherheit.

A E-Mail-Editoren kodieren Leerzeichen und Sonderzeichen oft halbherzig. Dein Link sieht im Editor sauber aus, enthält aber ein rohes Leerzeichen — das wird erst beim Versand zu %20 oder bricht den Link sogar ab. Dekodiere den Link vorher mit diesem Tool, um die tatsächlichen Zeichen zu sehen. Findest du ein einsames `&` statt `&`, hast du HTML-Kodierung, kein URL-Encoding. Mein Tipp: kodiere den gesamten Query-String mit `encodeURIComponent` und füge ihn dann erst in die Vorlage ein.

A Der Dekodierer zeigt dir einfach die ursprünglichen Prozent-Byte-Sequenzen an, mehr nicht. `%2520` wird zum Beispiel beim ersten Durchlauf zu `%20`, nicht zu einem Leerzeichen. Wenn du Doppelkodierung vermutest, führe ihn einfach erneut aus — erst beim zweiten Durchlauf siehst du das Leerzeichen. In meiner Erfahrung kodieren Datenpipelines Query-Strings manchmal versehentlich dreifach, also prüfe die Logs zweimal. Tipp: Beim Bereinigen von Tabellen-Exports einmal dekodieren und dann nach verbleibenden `%`-Zeichen suchen.

A Nein, und wer das verwechselt, bekommt schnell Probleme. URL-Encoding nutzt Prozentzeichen mit Hex-Werten – ein Leerzeichen wird zu %20. Base64 verwendet dagegen ein völlig anderes Alphabet aus A-Z, a-z, 0-9, Plus und Schrägstrich, um Binärdaten als Text zu packen. Versuch hier mal einen Base64-String zu dekodieren, du bekommst Quatsch oder eine Fehlermeldung. So erkennst du den Unterschied: Base64-Strings enden oft mit = als Auffüllung und sind deutlich länger als ihre Quelle. Wenn du signierte Links für eine API baust, prüf die Doku genau: Manche Systeme erwarten Base64url, das + und / durch - und _ ersetzt. Diese Variante funktioniert in unserem Tool auch nicht korrekt.