Base64-Rechner: Text sicher kodieren und dekodieren

Technik & Digital

Base64 online berechnen: UTF-8-Text sicher kodieren, Base64-Strings dekodieren und Padding...

Quelle: UTF-8-Textkodierung und Base64 nach RFC 4648 mit Formatprüfung, Stand Mai 2026.Stand: Juni 2026

Eingabe

Hier Werte eingeben und Optionen anpassen.

Überblick

Was ist der Base64-Encoder-Decoder?

Starte mit der kurzen Einordnung, bevor du Eingaben und Ergebnis interpretierst.

Der Base64-Encoder-Decoder ist für Entwickler, Admins und QA gedacht, die Text für APIs, Header oder Mail-Payloads in Base64 umwandeln oder bestehende Strings zurücklesen müssen. Base64 ist kein Verschlüsselungsverfahren, sondern ein Transportformat: Es bildet beliebige Bytes auf 64 druckbare ASCII-Zeichen ab, nämlich A bis Z, a bis z, die Ziffern 0 bis 9 sowie die Zeichen + und /.

Dadurch lassen sich auch binäre Daten oder Sonderzeichen sicher durch Systeme schleusen, die nur reinen Text erwarten, etwa HTTP-Header, JSON-Felder oder E-Mail-Anhänge.

Am Ende eines Base64-Strings stehen oft ein oder zwei Gleichheitszeichen als Padding, das die Länge auf ein Vielfaches von vier auffüllt.

Der Encoder wandelt UTF-8-Text in diesen Zeichensatz um, der Decoder liest einen Base64-String wieder in Klartext zurück.

So erkennst du sofort, ob ein String gültig ist und ob Padding oder Zeichensatz zur Quelle passen, etwa beim Basic-Auth-Header oder einem Token aus einem API-Log.

Eingaben

So nutzt du den Rechner

Hier siehst du, welche Werte erwartet werden und wie die Felder zusammenhängen.

Wähle, ob du Text kodieren oder Base64 zurück in Text dekodieren möchtest. Im Encode-Modus gibst du normalen UTF-8-Text ein; im Decode-Modus fügst du den Base64-String ein, wie er aus API-Logs, Headern oder Exporten stammt.

Achte beim Einfügen darauf, dass keine Zeilenumbrüche oder Leerzeichen mitkopiert werden, denn die gehören nicht zum eigentlichen Wert.

Das Padding am Ende, also ein oder zwei Gleichheitszeichen, lässt du stehen, da der Decoder es zur Längenprüfung braucht.

Ein häufiger Eingabefehler ist, eine URL-safe Variante, die statt + und / die Zeichen - und _ verwendet, oder abgeschnittenes Padding mit dem Standard-Base64-Format zu verwechseln; dann meldet der Rechner einen ungültigen Zeichensatz statt eines Ergebnisses.

Berechnung

So funktioniert die Berechnung

Verstehe den Formelweg.

Base64 gruppiert jeweils 3 Bytes zu 24 Bit und teilt diese in 4 Blöcke zu je 6 Bit auf; jeder 6-Bit-Block ergibt einen Wert von 0 bis 63, der über das Base64-Alphabet auf eines der 64 Zeichen abgebildet wird. Weil aus 3 Eingabe-Bytes immer 4 Ausgabe-Zeichen entstehen, wächst die Länge um etwa 33 Prozent.

Geht die Byte-Zahl nicht glatt durch 3 auf, füllt das Verfahren den letzten Block mit Nullbits und ergänzt ein oder zwei Gleichheitszeichen als Padding.

Beispiel: Aus dem Wort mit fünf Buchstaben Hallo wird so SGFsbG8= mit acht Base64-Zeichen, davon ein Padding-Zeichen.

Beim Dekodieren prüft der Rechner zuerst Länge, erlaubte Zeichen und Padding, übersetzt jedes Zeichen zurück in 6 Bit, fügt sie zu Bytes zusammen und gibt den Text wieder in UTF-8 aus.

Hinweise

Wichtige Hinweise zur Nutzung

Schnelle Qualitätsprüfung für dein Ergebnis.

Wenn du 'Hallo Welt' eingibst, zeigt das Ergebnis: 'SGFsbG8gV2VsdA==' – der Base64-codierte String ohne Zeilenumbrüche. Das bedeutet fachlich: 10 Zeichen Klartext ergeben 16 Base64-Zeichen, weil je 3 Bytes immer in 4 Zeichen kodiert werden.

Als nächsten Schritt gibst du 'SGFsbG8gV2VsdA==' im Decode-Modus ein: Du erhältst wieder 'Hallo Welt' – damit prüfst du, ob ein API-Payload sauber kodiert und dekodiert werden kann, ohne Skript oder Entwicklungsumgebung. Als Praxisbeispiel: PNG-Icon 2 kB wird in der Ausgabe als Base64-String mit rund 2,7 kB sichtbar – der 33-%-Overhead zeigt direkt, ob Inline-Embedding oder ein externer Link die bessere Wahl ist.

Anwendung

Praxisbeispiel und Einordnung

So wird das Ergebnis in einer realen Entscheidung nutzbar.

Lukas integriert eine REST-API, die einen Authentifizierungsheader im Basic-Auth-Format erwartet. Der Wert wird aus Benutzername und Passwort gebildet, getrennt durch einen Doppelpunkt: user:passwort123. Diese Zeichenkette ist 16 Bytes lang.

Er trägt sie in den Base64-Encoder ein. Da je 3 Bytes 4 Zeichen ergeben und 16 nicht glatt durch 3 teilbar ist, entstehen 24 Base64-Zeichen mit zwei Gleichheitszeichen als Padding: dXNlcjpwYXNzd29ydDEyMw==.

Er setzt den Header als Authorization: Basic dXNlcjpwYXNzd29ydDEyMw== und testet den API-Call. Zur Verifikation gibt er den Base64-String im Decode-Modus ein und erhält wieder user:passwort123 – der Wert stimmt.

Damit schließt er in 30 Sekunden einen Tippfehler im manuell gesetzten Header aus, den er sonst erst im Netzwerk-Log entdeckt hätte.

Fallstricke

Häufige Fehler und fachliche Einordnung

Typische Anfängerfehler. Sicherer anwenden.

Viele halten Base64 für Verschlüsselung und schicken sensible Inhalte deshalb in falscher Sicherheit weiter, obwohl der Rechner nur ein Text-Transportformat prüft. Häufig wird außerdem ein JWT-Teil, ein URL-safe-Token oder ein gekürzter String mit Standard-Base64 verwechselt; dann liegt der Fehler meist im Alphabet oder fehlendem Padding und nicht im Tool.

Ein dritter Fehler ist, den Decoder für beliebige Dateien zu nutzen und aus unlesbarer UTF-8-Ausgabe auf kaputte Daten zu schließen. Der Rechner hilft bei Textprüfung und Formatfehlern, nicht beim Anzeigen binärer Inhalte.

Nächster Schritt

Kurzfazit und nächster sinnvoller Schritt

Die Kernaussage für die direkte Weiterentscheidung.

Der Base64-Encoder/Decoder wandelt Text sofort in das Base64-Transportformat um und zurück und hilft Entwicklern, API-Payloads, Authorization-Header und eingebettete Strings in Logs oder Requests schnell zu prüfen, ohne Skripte oder Entwicklungswerkzeuge zu öffnen. Als nächsten Schritt kopierst du einen unbekannten Base64-String aus einem API-Log in den Decode-Modus und siehst sofort, ob der Inhalt lesbarer Text, ein fehlerhafter Payload oder ein nicht-textueller Wert ist.

Vertiefung

Beispielrechnungen

Step-by-Step Walkthroughs. Realistische Szenarien.

Beispiel 1 · Einfach · Base64: SGFsbG8gV2VsdA==

Text zu Base64 codieren

Text: Hallo Welt

Expertenmodus

Häufige Fragen zu Base64-Encoder-Decoder

Spezielle Fragen geklärt. Tiefer verstehen.

Wann nutze ich im Base64-Rechner Encode und wann Decode?

Encode wählst du für den Weg von lesbarem Klartext hin zu einer Base64-Zeichenfolge, Decode für den Rückweg von Base64 zurück zum ursprünglichen Inhalt.

Der Rechner zeigt dir unmittelbar, ob das Ergebnis als erwarteter Text herauskommt oder nur als unplausibler Rest stehen bleibt, und macht so Richtungsfehler sofort sichtbar.

Ein typischer Praxisfall ist ein API-Payload, der im Log unlesbar wirkt; hier kannst du in wenigen Sekunden prüfen, ob ein echter Encoding-Fehler vorliegt oder nur die Darstellungsrichtung verwechselt wurde.

Achte darauf, dass beim Encode der Eingabetext erkennbar länger wird, während beim Decode aus vier Base64-Zeichen wieder drei Bytes Originaldaten entstehen.

Genau diese Längenänderung ist ein schneller Indikator dafür, ob du den richtigen Modus verwendest und ob deine Eingabe überhaupt zur gewählten Operation passt.

Welche Eingaben akzeptiert der Rechner beim Dekodieren wirklich?

Der Rechner erwartet beim Dekodieren Standard-Base64 mit dem klassischen Alphabet aus A bis Z, a bis z, den Ziffern 0 bis 9 sowie den Sonderzeichen Plus und Schrägstrich, ergänzt um eine Länge, die durch vier teilbar ist.

Genau an dieser Stelle scheitern viele Eingaben aus dem Alltag, etwa wenn URL-safe Varianten mit Minus und Unterstrich oder ein abgeschnittenes Padding mit fehlenden Gleichheitszeichen übernommen werden.

Verletzt der String diese Grundregeln, lehnt der Rechner die Eingabe bewusst ab, statt stillschweigend ein falsches Ergebnis zu liefern.

Drei korrekt kodierte Bytes ergeben dabei immer vier Zeichen, weshalb Längen wie 5 oder 7 Zeichen technisch unmöglich sind. Prüfe deshalb vor dem Dekodieren, ob Padding, Alphabet und Gesamtlänge wirklich zur Standard-Spezifikation passen.

Wie entsteht Base64 technisch aus normalem Text?

Base64 gruppiert jeweils drei Bytes des Eingangstextes zu einem Block aus 24 Bit und teilt diesen anschließend in vier Einheiten zu je sechs Bit auf.

Jede dieser Sechs-Bit-Einheiten kann genau 64 verschiedene Werte annehmen, die dann auf das Base64-Alphabet aus 64 druckbaren Zeichen abgebildet werden.

Aus drei Bytes entstehen so immer vier Zeichen, was die Darstellung gegenüber dem Original um rund ein Drittel verlängert.

Bleibt am Ende ein unvollständiger Block, weil die Byteanzahl nicht glatt durch drei teilbar ist, füllt das Verfahren mit dem Gleichheitszeichen als Padding auf.

Genau deshalb spielen saubere Blocklängen und korrektes Padding beim späteren Dekodieren eine so große Rolle, und der Rechner macht diesen Zusammenhang an jedem Beispiel direkt nachvollziehbar.

Warum ist Base64 keine Verschlüsselung?

Base64 ist deshalb keine Verschlüsselung, weil es lediglich eine andere Darstellung exakt derselben Daten erzeugt und dabei keinerlei Schlüssel oder Geheimnis verwendet.

Jeder, der die kodierte Zeichenfolge in die Hand bekommt, kann sie ohne zusätzliche Information vollständig und eindeutig wieder zurückwandeln.

Die Ausgabe des Rechners macht das anschaulich; du kodierst einen Text und dekodierst ihn unmittelbar wieder, und dabei kommt verlustfrei der Ausgangsinhalt heraus.

Wer sensible Daten wirklich schützen will, braucht echte Verfahren wie AES oder TLS, die mit Schlüsseln arbeiten.

Base64 dient stattdessen dem sicheren Transport von Binärdaten über textbasierte Kanäle wie E-Mail-Header oder JSON, nicht dem Verbergen von Inhalten vor unbefugten Augen.

Warum wird Base64 ungefähr ein Drittel größer als der Ursprungstext?

Der Zuwachs entsteht, weil jeweils drei Original-Bytes als vier Base64-Zeichen dargestellt werden, was einem Verhältnis von genau vier zu drei und damit einem Plus von rund 33 Prozent entspricht.

Aus 24 Bit Nutzdaten werden also 32 Bit Textrepräsentation, da jedes Base64-Zeichen nur sechs der acht möglichen Bit eines Bytes ausnutzt.

Hinzu kommt bei kurzen Eingaben das Padding mit Gleichheitszeichen, das die Länge zusätzlich auf ein Vielfaches von vier aufrundet.

Der Rechner hilft dir genau dann, wenn du diese Größenfolge für Data-URIs, HTTP-Header oder eingebettete Mail-Anhänge realistisch einschätzen willst.

So erkennst du frühzeitig, ob ein eingebettetes Bild ein knappes Größenlimit sprengen könnte, bevor du es überhaupt versendest oder in den Quelltext einbaust.

Wann muss ich vor dem Dekodieren prüfen, ob mein String URL-safe-Base64 statt Standard-Base64 ist?

Diese Prüfung ist immer dann nötig, wenn der String aus einer URL, einem Cookie, einem JWT oder einem anderen webnahen Kontext stammt, denn dort kommt häufig die URL-safe Variante zum Einsatz.

Bei ihr werden die in URLs problematischen Zeichen Plus und Schrägstrich durch Minus und Unterstrich ersetzt, und das Padding mit Gleichheitszeichen wird oft ganz weggelassen.

Der Rechner ist bewusst auf das klassische Standard-Alphabet ausgelegt und interpretiert die ersetzten Zeichen daher anders.

Wenn du also einen Wert aus Tokens, JWT-Segmenten oder Query-Parametern vor dir hast, solltest du zuerst prüfen, ob überhaupt dasselbe Alphabet vorliegt.

Tausche bei Bedarf Minus und Unterstrich zurück und ergänze fehlendes Padding, bevor du den String in den Decoder gibst.

Warum kommt beim Dekodieren manchmal unlesbarer Text heraus?

Unlesbarer Text entsteht, weil Base64 nicht nur Buchstaben, sondern beliebige Binärdaten transportieren kann, der Rechner das Ergebnis aber als UTF-8-Text zu interpretieren versucht.

War die ursprüngliche Quelle gar kein Klartext, sondern etwa ein PNG-Bild, eine ZIP-Datei oder ein Kryptoschlüssel, ergeben die dekodierten Bytes keine sinnvolle Zeichenfolge und erscheinen als wirres Durcheinander.

Dasselbe passiert, wenn die Daten zwar Text sind, aber in einem anderen Zeichensatz wie Latin-1 statt UTF-8 vorlagen. Die Base64-Struktur kann dabei formal völlig korrekt sein, obwohl die Ausgabe kaputt wirkt.

Genau deshalb solltest du Quelle, erwarteten Zeichensatz und Nutzungszweck immer gemeinsam prüfen, bevor du aus einer scheinbar fehlerhaften Ausgabe auf einen echten Dekodierfehler schließt.

Warum scheitert ein JWT-Teil oder URL-Parameter trotz ähnlicher Zeichenfolge im Decoder?

Solche Quellen scheitern, weil sie meist URL-safe-Base64 ohne das klassische Gleichheitszeichen-Padding verwenden oder oft nur einen einzelnen Segmentausschnitt liefern.

Ein JWT besteht etwa aus drei durch Punkte getrennten Teilen, von denen jeder für sich kodiert ist; kopierst du versehentlich Trennpunkte mit oder nur ein Fragment, passt die Länge nicht mehr zum Viererraster.

Der Rechner ist bewusst auf Standard-Base64 für die Textprüfung ausgelegt und verarbeitet deshalb nicht jede tokenartige Zeichenfolge als direkt dekodierbaren Eingabe-String.

Gerade darin liegt sein praktischer Nutzen; er macht sichtbar, ob du wirklich sauberes Standard-Base64, eine URL-safe-Variante oder lediglich einen unvollständigen Ausschnitt aus Header, Token oder Parameter vor dir hast, und zwingt dich so zu einer bewussten Aufbereitung der Eingabe.

Weiterführende Rechner und Themen

Alle Anschlussrechner und Vertiefungen in einem klaren Modul, damit du direkt zur nächsten sinnvollen Berechnung springen kannst.

ASCII-CodesEinzelne Zeichen in ASCII-Dezimal-, Hex- oder Binärcodes umwandeln.ZahlenbasisByte-Werte zwischen Binär, Oktal, Dezimal und Hex umrechnen.Datenvolumen-RechnerDatenverbrauch für Streaming, Surfen, Videocalls, Social Media und Gaming pro Tag, Woche oder Monat abschätzen.Farb-KonverterFarben zwischen HEX, RGB und HSL umrechnen – mit Farbvorschau und fertigen CSS-Codes zum Kopieren.Timestamp-KonverterUnix-Timestamps in Datum/Uhrzeit und umgekehrt konvertieren – inklusive Sekunden- und Millisekunden-Timestamps sowie Zeitzonen.Cloud-Speicherbedarf-RechnerBenötigten Cloud-Speicher für Fotos, Videos und Dokumente berechnen und passenden Cloud-Tarif mit Puffer finden.Backup-Größe-RechnerBackup-Größe für Voll-, inkrementelle und differenzielle Backups mit Komprimierung und geschätzter Backup-Dauer berechnen.Programmierung & Entwickler Rechner gezielt auswählenDirekter Hub für weitere Rechner aus Programmierung & Entwickler mit demselben Themenkontext.Technik & Digital als Themenhub weiter öffnenCluster-Wechsel in benachbarte Themen derselben Kategorie.Base64-Encoder-Decoder über alle Filter weiter eingrenzenSuche für weitere Varianten, Kategorien und Rechentypen mit ähnlichem Intent.