Kodierung-Tools

Online-Kodierungswerkzeuge - Base64 und URL-Kodierung im Browser

Aktualisiert am 29. September 2026 · Von Saman

Kodierung ist keine Verschlüsselung. Sie verbirgt nichts und schützt nichts. Ihre Aufgabe ist es, Daten, die etwas kaputtmachen würden - einen Kanal, der nur Text transportiert, eine URL, die & als Trennzeichen versteht, einen E-Mail-Header aus der Zeit vor Unicode - in Zeichen umzuformen, die die Reise überstehen. Die Werkzeuge dieser Kategorie tun das in beide Richtungen, vollständig in Ihrem Browser.

Diese Unterscheidung verdient Deutlichkeit, denn sie ist das mit Abstand häufigste Missverständnis in diesem Bereich. Base64 ist von jedem sofort umkehrbar, ohne Schlüssel. Ein als Base64 gespeichertes Passwort ist ein im Klartext gespeichertes Passwort mit einem Zwischenschritt. Wer Geheimhaltung braucht, braucht Kryptografie, keine Kodierung.

Was in dieser Kategorie steckt

Was Base64 wirklich macht

Base64 nimmt drei Bytes auf einmal - 24 Bit - und schreibt sie als vier Zeichen aus einem 64-Zeichen-Alphabet: A-Z, a-z, 0-9 sowie + und /. Weil 64 gleich 2 hoch 6 ist, trägt jedes Ausgabezeichen genau sechs Bit. Geht die Eingabe nicht glatt durch drei, wird mit = aufgefüllt, damit die Länge immer ein Vielfaches von vier ist.

Die Folge ist Arithmetik, keine Meinung: Base64-Ausgabe ist rund 33% größer als die Eingabe. Ein 300 KB großes Bild für ein Stylesheet zu kodieren ergibt etwa 400 KB Text. Das kostet wirklich und ist der Grund, warum sich Inlining bei kleinen Icons lohnt und bei Fotos selten.

Die Zeichen + und / sind in URLs ein Problem, wo sie bereits eine Bedeutung haben. URL-sicheres Base64 ersetzt sie durch - und _ und lässt das Padding meist weg. Diese Variante nutzen JSON Web Tokens, und die Verwechslung der beiden ist der Grund, warum ein Token in einem Werkzeug scheitert und im anderen funktioniert.

Was Prozentkodierung wirklich macht

Eine URL hat eine Grammatik. ? beginnt den Query-String, & trennt Parameter, = verbindet Name und Wert, # beginnt das Fragment, und ein Leerzeichen ist gar nicht erlaubt. Enthält ein Wert eines dieser Zeichen, muss es maskiert werden, sonst bedeutet die URL etwas anderes als beabsichtigt. Prozentkodierung ersetzt das Zeichen durch % plus seinen Bytewert in Hexadezimal: Leerzeichen wird %20, & wird %26, / wird %2F.

Nicht-ASCII-Text wird als seine UTF-8-Bytes kodiert, ein %XX pro Byte. Ein einzelnes persisches oder japanisches Zeichen wird meist zu drei Escapes. Deshalb sieht eine URL mit einem Suchbegriff in nicht-lateinischer Schrift so viel länger aus als der Begriff selbst.

Die Falle liegt darin, zu wissen, welchen Teil der URL man kodiert. Kodiert man die ganze URL, werden :// und / zu Escapes und sie ist zerstört. Fast immer will man einen Parameterwert kodieren und die URL darum herum bauen. Der URL-Encoder kann beides, die Entscheidung bleibt bei Ihnen.

Zahlensysteme: die Kodierung unter allen anderen

Base64 und Prozentkodierung arbeiten beide mit Bytes, und Bytes werden meist hexadezimal oder binär geschrieben. Der Zahlensystem-Umrechner liest einen Wert in jeder Basis und zeigt ihn sofort in den anderen, ohne 64-Bit-Grenze, und sein Reiter Text zeigt die UTF-8-Bytes hinter einer Zeichenkette. So sieht man am schnellsten, warum é zwei Bytes belegt, warum %C3%A9 seine prozentkodierte Form ist und warum 0xFF gleich 255 ist.

Wo Ihnen diese Kodierungen begegnen

• Data-URIs - data:image/png;base64,... bettet ein Bild direkt in HTML oder CSS ein und spart eine Anfrage.
• HTTP Basic Auth - der Header ist buchstäblich Basic plus Base64 von benutzer:passwort. Von jedem umkehrbar, der ihn sieht, weshalb er nur innerhalb von TLS etwas zu suchen hat.
• JSON Web Tokens - drei URL-sichere Base64-Segmente, durch Punkte verbunden. Die Payload ist ohne jeden Schlüssel lesbar.
• E-Mail-Anhänge - MIME transportiert Binärdaten seit den frühen 1990ern als Base64, bis heute.
• Query-Strings - jeder Suchbegriff, jedes Weiterleitungsziel, jeder Filterwert mit Leerzeichen oder Sonderzeichen.
• Konfigurations- und Secret-Dateien - Kubernetes-Secrets, Service-Account-Schlüssel und Zertifikate liegen routinemäßig Base64-kodiert vor.

Typische Fehler und ihre Ursachen

• Doppelte Kodierung. Ein Wert wird von Ihrem Code und noch einmal vom Framework kodiert, aus %20 wird %2520. Sehen Sie %25 in einer URL, hat etwas ein Prozentzeichen kodiert, das schon ein Escape war.
• Falsches Base64-Alphabet. Ein JWT, das sich nicht dekodieren lässt, ist meist URL-sicheres Base64 in einem Standard-Dekoder - oder umgekehrt.
• Fehlendes Padding. Manche Erzeuger lassen das abschließende = weg. Strenge Dekoder lehnen das Ergebnis ab, nachsichtige ergänzen es.
• Die ganze URL kodiert. Schema und Pfad werden maskiert, der Link löst nicht mehr auf.
• Sicherheit angenommen. Base64 in einem Cookie, einem Header oder einer Konfigurationsdatei ist für jeden lesbar, der die Datei lesen kann.
• Pluszeichen im Query-String. In formularkodierten Daten bedeutet + Leerzeichen, in einem Pfad ein echtes Plus. Dasselbe Zeichen, zwei Bedeutungen.

Warum es zählt, dass das lokal läuft

Die Zeichenketten, die man kodieren und dekodieren muss, sind überdurchschnittlich sensibel: Authorization-Header, Session-Tokens, Service-Account-Schlüssel, signierte URLs. Eine davon in eine Website einzufügen, die sie serverseitig verarbeitet, übergibt einem Dritten eine gültige Zugangsberechtigung. Beide Werkzeuge hier laufen im Browser - die Eingabe verlässt den Tab nie, und Sie können das im Netzwerk-Panel nachprüfen.

Verwandte Kategorien

• Textwerkzeuge - das JSON formatieren und validieren, das so oft in einer kodierten Payload steckt.
• Entwicklerwerkzeuge - ein JWT sauber dekodieren, statt seine Teile von Hand zu base64en, oder einen Wert hashen, wenn Sie einen Fingerabdruck statt einer umkehrbaren Form brauchen.
• Generatoren - die Bezeichner und Secrets erzeugen, die später kodiert werden.