Ist Base64 eine Verschlüsselung?

Nein. Base64 ist eine reversible Kodierung ohne Schlüssel. Jeder kann den String in Millisekunden in den Klartext zurückverwandeln. Nutzen Sie für Vertraulichkeit AES-GCM, ChaCha20-Poly1305 oder TLS — Base64 darf nur als Transport-Verpackung oberhalb dieser Schichten dienen.

Warum wird mein Base64-String länger als das Original?

Weil pro 3 Eingabe-Bytes 4 Ausgabe-Zeichen entstehen — ein Overhead von genau 4/3, also ca. 33%. Hinzu kommen bis zu zwei = -Padding-Zeichen am Ende. Ein 100-Byte-Input wird also rund 136 Zeichen Output.

Was bedeuten die = -Zeichen am Ende?

Sie sind Padding. Base64 verarbeitet immer Blöcke von 3 Bytes; ist die Länge nicht durch 3 teilbar, füllt der Algorithmus mit Null-Bits auf und markiert die ungenutzten 6-Bit-Gruppen mit = . Es gibt nie mehr als zwei = am Ende.

Warum bekomme ich "InvalidCharacterError" bei Umlauten?

Weil das eingebaute btoa() nur Latin-1 (Codepoints 0–255) akzeptiert. Ein ö ist Codepoint 246 — Latin-1 ok, aber ein ß oder Emoji nicht. Lösung: erst per new TextEncoder().encode(str) in UTF-8-Bytes konvertieren, dann diese Bytes Base64-kodieren. Unser Tool macht das automatisch.

Was ist der Unterschied zwischen Base64 und Base64URL?

Base64URL (RFC 4648 §5) ersetzt + durch - , / durch _ und lässt das = -Padding meist weg. Dadurch passt der String ohne Prozent-Encoding in URLs, Cookies und Dateinamen. JWT, OAuth-PKCE und WebPush nutzen Base64URL.

Sind die Daten beim Tool wirklich privat?

Ja. Die gesamte Kodierung läuft in JavaScript direkt in Ihrem Browser. Es findet kein Upload zu CalcSI statt; Sie können die Seite sogar laden, das Netzwerk trennen und das Tool funktioniert weiter. Auch Dateien werden nur via FileReader lokal gelesen.

Base64 Encoder/Decoder

Text, Bilder und Dateien in Base64 kodieren oder Base64 dekodieren.

{{ mode === 'encode' ? __t('label_plain_text') : __t('label_base64_input') }}

{{ mode === 'encode' ? __t('label_base64_output') : __t('label_decoded_output') }}

Eingabegröße: {{ inputSize }} | Ausgabegröße: {{ outputSize }} Base64 erkannt → Dekodierung

Datei hochladen

Datei hierher ziehen oder klicken zum Auswählen

{{ fileInfo.name }} ({{ formatBytes(fileInfo.size) }}) — {{ fileInfo.type || 'unknown' }}

Vorschau

Base64 Data URI

Ausgabegröße: {{ formatBytes(fileDataUri.length) }}

Was ist Base64-Kodierung?

Base64 ist ein Kodierungsverfahren, das binäre Daten in einen ASCII-String umwandelt. Dabei werden jeweils 3 Bytes in 4 druckbare Zeichen (A–Z, a–z, 0–9, +, /) konvertiert. Das Ergebnis ist etwa 33 % größer als die Originaldaten, dafür aber sicher in Textprotokollen wie E-Mail, JSON oder HTML einbettbar.

Wie funktioniert Base64?

Der Algorithmus nimmt den Eingabe-Bytestream und teilt ihn in Blöcke von je 3 Bytes (24 Bit). Jeder Block wird in vier 6-Bit-Gruppen aufgeteilt, die als Index in ein 64-Zeichen-Alphabet dienen. Ist die Länge nicht durch 3 teilbar, werden Padding-Zeichen (=) angehängt. Das Ergebnis ist ein reiner ASCII-Text.

Typische Anwendungsfälle

Bilder als Data-URIs in CSS oder HTML einbetten, um HTTP-Requests zu sparen.
Binärdaten in JSON-APIs oder XML-Dokumenten transportieren.
E-Mail-Anhänge über MIME kodieren.
Tokens und Credentials in URLs oder Headern sicher übertragen (z.B. HTTP Basic Auth).

Base64 im Detail: Spezifikation und Varianten

Base64 ist in RFC 4648 standardisiert und gehört zur Familie der Binary-to-Text-Encodings. Es existiert, weil viele Protokolle aus den 1980er-Jahren (SMTP, FTP, HTTP-Header) nur 7-Bit-ASCII zuverlässig übertragen. Rohbinärdaten wie Bilder, kompilierte Programme oder verschlüsselte Payloads würden in solchen Kanälen durch Steuerzeichen, Zeilenende-Konvertierungen oder Encoding-Annahmen beschädigt. Base64 löst das Problem, indem es jedes Byte-Tripel (24 Bit) in vier ASCII-Zeichen aus dem Alphabet A-Z a-z 0-9 + / zerlegt und am Ende mit dem Padding-Zeichen = auf ein Vielfaches von 4 auffüllt.

Neben der Standard-Variante definiert RFC 4648 auch Base64URL, das + durch - und / durch _ ersetzt, damit der String ohne Prozent-Encoding in URLs und Dateinamen passt. JSON Web Tokens (JWT), OAuth-Codes und WebPush-Subscriptions nutzen genau diese Variante. Außerdem gibt es MIME-Base64 (RFC 2045) mit Zeilenumbruch nach 76 Zeichen — relevant für E-Mail-Anhänge — sowie Base32 und Base16 (Hex). Unser Tool verwendet die Standard-RFC-4648-Variante; bei Bedarf konvertieren Sie zwischen Standard und URL-safe, indem Sie die genannten Zeichen ersetzen.

Wichtig: Base64 ist keine Verschlüsselung. Jeder kann den String mit zwei Zeilen Code zurück in die Originaldaten verwandeln. Verwenden Sie Base64 nur als Transport-Layer, niemals zum Schutz von Passwörtern, API-Keys oder personenbezogenen Daten. Für vertrauliche Inhalte gehört vor das Base64 immer ein echter Krypto-Layer wie AES-GCM oder eine signierte Token-Struktur wie JWT mit RS256.

So nutzen Sie den Base64 Encoder/Decoder

Das Tool arbeitet komplett im Browser — Ihre Daten verlassen den Rechner nicht. So gehen Sie in fünf Schritten vor:

Wählen Sie oben den passenden Modus: Kodieren für Text → Base64, Dekodieren für Base64 → Text, oder Datei/Bild für Binärdateien zu Data URIs.
Fügen Sie Ihren Text oder Base64-String in das linke Feld ein. Das Tool erkennt automatisch, ob die Eingabe wie gültiges Base64 aussieht, und wechselt bei Bedarf in den Dekodier-Modus.
Bei Dateien ziehen Sie das File (z.B. logo.png, icon.svg) in die Drop-Zone oder klicken Sie hinein, um einen Dialog zu öffnen. Bilder erhalten zusätzlich eine Live-Vorschau.
Das Ergebnis erscheint rechts mit Größenanzeige für Eingabe und Ausgabe — typisch sind +33% durch das Encoding. Bei Dateien bekommen Sie direkt einen vollständigen data:-URI inklusive MIME-Type, etwa data:image/png;base64,iVBORw0KGgo....
Klicken Sie auf das Copy-Symbol, um den String in die Zwischenablage zu übernehmen. Von dort fügen Sie ihn in CSS (background-image:url('data:...')), JSON-Payloads, curl-Befehle oder Dokumentationen ein.

Praxisbeispiele

Diese Beispiele zeigen typische Ein- und Ausgaben, die Sie im Alltag begegnen:

Text → Base64: Hello, World! wird zu SGVsbG8sIFdvcmxkIQ== (14 Bytes → 20 Zeichen, zwei = als Padding).
HTTP Basic Auth: Benutzername admin und Passwort secret werden als admin:secret verkettet und ergeben den Header Authorization: Basic YWRtaW46c2VjcmV0.
Inline-SVG in CSS: ein 1x1 transparentes PNG ergibt data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII=, direkt nutzbar als background-image.
JWT-Header: {"alg":"HS256","typ":"JWT"} wird Base64URL-kodiert zu eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 (kein Padding, -_ statt +/).
UTF-8-Sicherheit: Schöne Grüße wird korrekt zu U2Now7ZuZSBHcsO8w59l. Der Trick ist, vor btoa() zuerst per TextEncoder in Bytes zu konvertieren — sonst wirft JavaScript bei Umlauten InvalidCharacterError.

Grenzen, Stolperfallen und Sicherheit

Base64 ist robust, hat aber Eigenheiten. Erstens: Overhead. Ein 1 MB-Bild wird zu rund 1,33 MB Text — schlecht für mobile Bandbreite und Cache-Effizienz, vor allem wenn dasselbe Asset auf vielen Seiten erscheint. Zweitens: UTF-8-Falle. Der eingebaute btoa() in Browsern erwartet Latin-1, nicht UTF-8 — Umlaute, Emoji oder kyrillische Zeichen werfen InvalidCharacterError, wenn man nicht vorher per TextEncoder in Bytes umwandelt. Drittens: URL-safe vs. Standard. Wer einen Standard-Base64-String in eine URL klebt, muss +, / und = prozent-encoden, sonst bricht das Routing. Viertens: Whitespace und Padding. Viele Decoder akzeptieren Zeilenumbrüche und fehlendes Padding, andere nicht — bei API-Integrationen prüfen, ob beide Seiten dieselbe Variante (RFC 4648 strict vs. MIME) sprechen. Fünftens — sicherheitskritisch: Base64 verschleiert nichts. Logfiles, Source Maps und Browser-DevTools machen jeden eingebetteten Base64-String trivial lesbar. Speichern Sie niemals Klartext-Credentials, JWTs mit sensiblen Claims oder API-Secrets als Base64 in einer Datei oder URL. Wer reproduzierbar sicher senden will, kombiniert Base64 mit AES-GCM, HMAC oder TLS.

Häufige Fragen zu Base64

Ist Base64 eine Verschlüsselung?: Nein. Base64 ist eine reversible Kodierung ohne Schlüssel. Jeder kann den String in Millisekunden in den Klartext zurückverwandeln. Nutzen Sie für Vertraulichkeit AES-GCM, ChaCha20-Poly1305 oder TLS — Base64 darf nur als Transport-Verpackung oberhalb dieser Schichten dienen.
Warum wird mein Base64-String länger als das Original?: Weil pro 3 Eingabe-Bytes 4 Ausgabe-Zeichen entstehen — ein Overhead von genau 4/3, also ca. 33%. Hinzu kommen bis zu zwei =-Padding-Zeichen am Ende. Ein 100-Byte-Input wird also rund 136 Zeichen Output.
Was bedeuten die =-Zeichen am Ende?: Sie sind Padding. Base64 verarbeitet immer Blöcke von 3 Bytes; ist die Länge nicht durch 3 teilbar, füllt der Algorithmus mit Null-Bits auf und markiert die ungenutzten 6-Bit-Gruppen mit =. Es gibt nie mehr als zwei = am Ende.
Warum bekomme ich "InvalidCharacterError" bei Umlauten?: Weil das eingebaute btoa() nur Latin-1 (Codepoints 0–255) akzeptiert. Ein ö ist Codepoint 246 — Latin-1 ok, aber ein ß oder Emoji nicht. Lösung: erst per new TextEncoder().encode(str) in UTF-8-Bytes konvertieren, dann diese Bytes Base64-kodieren. Unser Tool macht das automatisch.
Was ist der Unterschied zwischen Base64 und Base64URL?: Base64URL (RFC 4648 §5) ersetzt + durch -, / durch _ und lässt das =-Padding meist weg. Dadurch passt der String ohne Prozent-Encoding in URLs, Cookies und Dateinamen. JWT, OAuth-PKCE und WebPush nutzen Base64URL.
Sind die Daten beim Tool wirklich privat?: Ja. Die gesamte Kodierung läuft in JavaScript direkt in Ihrem Browser. Es findet kein Upload zu CalcSI statt; Sie können die Seite sogar laden, das Netzwerk trennen und das Tool funktioniert weiter. Auch Dateien werden nur via FileReader lokal gelesen.