KeroTools

Base64-Kodierer und -Dekodierer

Kodieren Sie beliebigen Text in Base64 oder dekodieren Sie ihn sofort — kostenloses Tool für Entwickler.

Eingabe
0 Zeichen
Ausgabe

Ihr Text bleibt auf dem Gerät

Nichts, was später zu löschen wäre

Für das Dekodieren von Zugangsdaten gebaut

Läuft in jedem modernen Browser

So funktioniert es

  1. 1

    Text einfügen

    Klartext zum Kodieren oder eine Base64-Zeichenkette zum Dekodieren.

  2. 2

    Richtung und Alphabet wählen

    Kodieren oder dekodieren, Standard oder URL-sicher — je nachdem, wohin das Ergebnis geht.

  3. 3

    Ergebnis kopieren

    Nehmen Sie es in einen Header, einen data-URI, einen Konfigurationswert oder eine Anfrage.

Warum dieses Tool

Beide Alphabete

Standard-Base64 und die URL-sichere Variante, damit ein Token, das eine Abfragezeichenfolge überstehen muss, das auch tut.

Auffüllung in beide Richtungen behandelt

Eingabe mit oder ohne abschließende `=` wird dekodiert, und Sie wählen, was die Ausgabe trägt.

UTF-8 richtig gemacht

Arabisch, Türkisch und Emoji kommen unversehrt zurück, statt zu Ersatzzeichen zu zerfallen.

Sofort in beide Richtungen

Kodieren und Dekodieren am selben Ort, ohne mitten in einer Fehlersuche das Werkzeug zu wechseln.

Nichts wird hochgeladen

Die Umwandlung geschieht in Ihrem Browser — ein eingefügtes Token erreicht nie einen Server.

Kostenlos, ohne Konto

Keine Anmeldung, kein Wasserzeichen, keine Obergrenze für die Menge.

Base64 ist keine Verschlüsselung, und es dafür zu halten ist eine echte Schwachstelle

Das ist das Wichtigste an diesem Format, und es wird ständig missverstanden. Base64 hat keinen Schlüssel, kein Geheimnis und keinerlei Sicherheitseigenschaft. Es ist eine öffentliche, umkehrbare Zuordnung, die jeder in einem Schritt rückgängig macht — genau das tut diese Seite. Dennoch taucht Base64 regelmäßig als Ersatz für Schutz auf: Passwörter, die Base64-kodiert in einer Datenbank liegen, „verschleierte“ API-Schlüssel in einer Konfigurationsdatei, personenbezogene Daten in einem Cookie, damit es „nach nichts aussieht“. Nichts davon ist verborgen. Es ist bloß in einem anderen Alphabet geschrieben, und jede Person und jeder Scanner, der es findet, liest es sofort. Soll jemand einen Wert nicht lesen können, brauchen Sie Verschlüsselung oder Hashing — Base64 ist beides nicht.

Wozu es wirklich da ist: Bytes durch reine Textkanäle bringen

Base64 löst ein bestimmtes, unglamouröses Problem. Viele Systeme akzeptieren nur druckbaren Text: E-Mail-Rümpfe, JSON-Zeichenkettenfelder, HTTP-Header, XML-Dokumente, URLs. Geben Sie einem davon rohe Binärdaten — ein Bild, ein komprimiertes Archiv, einen Schlüssel — und irgendetwas auf dem Weg wird sie entstellen, denn Bytes, die zufällig wie Steuerzeichen oder Zeilenenden aussehen, werden unterwegs umgeschrieben. Base64 umgeht das, indem es beliebige Bytes mit 64 Zeichen ausdrückt, die alle Systeme übereinstimmend in Ruhe lassen. Deshalb steckt ein E-Mail-Anhang als Base64 in der Nachricht, deshalb ist ein eingebettetes Bild in CSS ein `data:`-URI, und deshalb wird ein binäres Zertifikat als PEM-Block geliefert. Das Format ist eine Transporthülle, kein Speicherformat und keine Sicherheitsmaßnahme.

Es kostet ein Drittel mehr Bytes, und manchmal zählt das

Die Rechnung ist fest: Aus je drei Eingabebytes werden vier Ausgabezeichen, kodierte Daten sind also vor der Auffüllung rund 33 Prozent größer als das Hineingegebene. Meistens ist das belanglos. Belanglos hört es auf zu sein, wenn Bilder als `data:`-URI in CSS oder HTML eingebettet werden, um eine HTTP-Anfrage zu sparen. Aus einem 90-KB-Bild werden 120 KB Zeichen, und anders als eine echte Bilddatei lässt es sich nicht separat zwischenspeichern, nicht verzögert laden, und es blockiert das Stylesheet, das es enthält. Für ein kleines Symbol ist das ein fairer Handel. Für ein Foto ist es meist ein Fehler, der sich später als langsames erstes Zeichnen zeigt. Wenn Sie etwas zum Einbetten kodieren, sehen Sie sich die Größe an, bevor Sie sich festlegen.

Das URL-sichere Alphabet gibt es, weil drei Zeichen URLs zerlegen

Standard-Base64 verwendet `+`, `/` und `=`, und alle drei bedeuten in einer URL etwas anderes. Das Pluszeichen wird in Abfragezeichenfolgen als Leerzeichen gelesen, der Schrägstrich ist ein Pfadtrenner, und das Gleichheitszeichen trennt einen Parameter von seinem Wert. Schicken Sie ein standardkodiertes Token durch eine URL, kommt es beschädigt an — oft so, dass es nur bei manchen Eingaben auffällt; deshalb ist „funktioniert in meinem API-Client, bricht im Browser“ eine so verbreitete Meldung. Die URL-sichere Variante behebt das, indem sie `-` für `+` und `_` für `/` setzt und die Auffüllung meist ganz weglässt. JWTs nutzen sie, ebenso die meisten modernen Tokenformate. Die beiden Alphabete sind nicht austauschbar: Eine URL-sichere Zeichenkette mit einem strengen Standarddekoder zu dekodieren scheitert — passen Sie die Variante dem Weg an, den der Wert genommen hat.

Was die Gleichheitszeichen am Ende tun

Die Auffüllung ist der Teil, den alle bemerken und bei dem niemand sicher ist. Weil die Kodierung mit Dreiergruppen arbeitet, lässt eine Eingabe, deren Länge kein Vielfaches von drei ist, eine unvollständige Gruppe zurück, und `=` füllt die Ausgabe auf ein Vielfaches von vier auf. Ein Gleichheitszeichen bedeutet, dass die Eingabe mit zwei übrigen Bytes endete; zwei bedeuten, sie endete mit einem. Mehr tragen sie nicht — sie sind ein Längenhinweis, keine Daten. In der Praxis sind sich Dekoder uneins, ob sie Pflicht sind: manche weisen ungefüllte Eingaben rundweg ab, manche nehmen sie an, und die URL-sichere Konvention lässt die Auffüllung meist weg, weil `=` in einer URL unhandlich ist. Scheitert ein Wert anderswo am Dekodieren und wirkt hier korrekt, lohnt sich vor exotischeren Ursachen ein Blick auf die Auffüllungserwartung.

Warum lokales Dekodieren hier mehr zählt als fast überall sonst

Sehen Sie sich an, was Menschen tatsächlich in einen Base64-Dekoder einfügen. Es ist ein `Authorization: Basic`-Header, der Benutzername und Passwort durch einen Doppelpunkt getrennt enthält. Es ist die Nutzlasthälfte eines JWT, die eine Benutzerkennung und oft eine E-Mail-Adresse trägt. Es ist eine Verbindungszeichenfolge, ein API-Schlüssel, ein Sitzungscookie, ein Zertifikat. Der ganze Grund, zu einem Dekoder zu greifen, ist ja, dass man einen unlesbaren Wert in der Hand hält — und unlesbare Werte sind überwältigend häufig Zugangsdaten. Diese in einen gehosteten Dekoder einzufügen übergibt ein funktionierendes Geheimnis an Dritte, über einen Kanal, der keine Spur hinterlässt. Dieses Werkzeug wandelt auf der Seite um und überträgt nichts, nachprüfbar im Netzwerk-Tab der Entwicklerwerkzeuge — und bei genau diesem Format ist das keine Feinheit.

Häufige Fehler, die Sie vermeiden sollten

  • Base64 verwenden, um etwas zu verbergen. Es gibt keinen Schlüssel und kein Geheimnis — jeder dekodiert es in einem Schritt; soll ein Wert unlesbar sein, braucht er Verschlüsselung oder Hashing, kein anderes Alphabet.
  • Einen standardkodierten Wert durch eine URL schicken. Die Zeichen `+`, `/` und `=` bedeuten dort etwas anderes; nutzen Sie das URL-sichere Alphabet, sonst kommt der Wert bei manchen Eingaben beschädigt an und bei anderen nicht.
  • Ein großes Bild als `data:`-URI einbetten. Die Kodierung fügt rund ein Drittel zur Größe hinzu, und das Ergebnis lässt sich weder separat zwischenspeichern noch verzögert laden — passabel für ein Symbol, teuer für ein Foto.
  • Annehmen, Auffüllung sei überall optional. Manche Dekoder verlangen die abschließenden `=`, manche lehnen sie ab; dekodiert ein Wert hier und scheitert anderswo, prüfen Sie das vor exotischeren Ursachen.
  • Einen Authorization-Header oder ein JWT in einen gehosteten Dekoder einfügen. Diese Werte sind aktive Zugangsdaten, und das Einfügen hinterlässt keine Spur — dekodieren Sie lokal.

Im Vergleich

KriteriumDieses WerkzeugOnline-DekoderEine Kommandozeile
Inhalt an einen Server gesendetNieMeistens jaNein
URL-sicheres AlphabetJaUnterschiedlichBraucht einen Schalter
UTF-8 korrekt behandeltJaUnterschiedlichJa
Einrichtung nötigKeineKeineEin Terminal
Konto oder AnmeldungNicht nötigOft verlangtNicht nötig
PreisKostenlosKostenlos / BezahltarifeKostenlos

Funktionen

Kodieren und dekodieren

Beide Richtungen an einem Ort, Eingabe und Ausgabe nebeneinander.

URL-sichere Variante

Das Alphabet mit `-` und `_`, das JWTs und alles Reisende in einer URL verwenden.

Optionale Auffüllung

Abschließende `=` ausgeben oder entfernen, passend zu dem, was das empfangende System erwartet.

Volle Unicode-Unterstützung

Text wird zuerst als UTF-8 kodiert, sodass nichtlateinische Schriften die Reise überstehen.

Verträgt große Eingaben

Lange Zeichenketten werden ohne Upload und ohne Größenobergrenze umgewandelt.

Ungültige Eingabe wird gemeldet

Eine Zeichenkette, die kein gültiges Base64 ist, sagt das, statt stillen Unsinn zurückzugeben.

Nichts zu installieren

Keine Kommandozeile, keine Laufzeitumgebung, keine Abhängigkeiten — es läuft auf der Webseite.

Bereit für Arabisch und RTL

Vollständige Oberfläche in acht Sprachen, darunter Arabisch von rechts nach links.

Standardmäßig sicher

Über HTTPS ausgeliefert, ohne Inhaltsverfolgung und ohne Upload an Dritte.

Wer es nutzt

Entwicklerinnen und Entwickler

Beim Debuggen einen Auth-Header oder eine Token-Nutzlast lesen, ohne sie Dritten zu übergeben.

Security-Engineering

Einen kodierten Wert prüfen, der in einem Protokoll, Cookie oder einer Konfigurationsdatei aufgetaucht ist.

API-Integratoren

Einen Basic-Auth-Header bauen oder prüfen, bevor eine Anfrage damit rausgeht.

Frontend-Entwicklung

Einen `data:`-URI für ein kleines eingebettetes Element erzeugen und sehen, was es an Größe kostet.

Häufig Gestellte Fragen

Nein. Alles läuft lokal im Browser — Ihr Text wird nie hochgeladen, gespeichert oder geteilt.

Ja — komplett kostenlos, ohne Konto und ohne Limits.