Kostenloser Online-Base64-Encoder & -Decoder

Was ist Base64?

Base64 ist ein Binär-zu-Text-Kodierungsschema, eine Möglichkeit, jede Bytefolge (Binärdaten) als Folge gewöhnlicher ASCII-Zeichen darzustellen, die durch reine Textkanäle laufen kann, ohne beschädigt zu werden. Der Name spiegelt die Alphabetgröße wider: 64 Zeichen, die speziell ausgewählt wurden, weil sie eine 7-Bit-saubere Übertragung unverändert überstehen. Das Standardalphabet ist A-Z (Positionen 0-25), a-z (26-51), 0-9 (52-61), dann + (62) und / (63). Das Zeichen = bleibt als Auffüllung reserviert, wenn die Eingabelänge kein exaktes Vielfaches von drei ist. Aus drei Eingabe-Bytes (24 Bit) werden vier Ausgabezeichen (jedes trägt 6 Bit), weshalb Base64-codierte Daten etwa 33 % größer als das Original sind.

Der Mechanismus: nimm drei Bytes (24 Bit), gruppiere sie als vier 6-Bit-Blöcke, schlage jeden Block im 64-Zeichen-Alphabet nach. Das klassische Beispiel: die drei ASCII-Bytes M a n (0x4D 0x61 0x6E) bilden das 24-Bit-Muster 01001101 01100001 01101110; neu gruppiert als 6-Bit-Blöcke: 010011 010110 000101 101110 = 19, 22, 5, 46 dezimal = Zeichen T W F u. Also kodiert "Man" in Base64 als "TWFu". Ist die Eingabelänge nicht durch drei teilbar, füllt der Encoder mit einem oder zwei = auf: 1 Byte Eingabe ergibt 2 Zeichen + ==, 2 Bytes Eingabe ergeben 3 Zeichen + =.

Eine kurze Geschichte von Base64

Base64 entstand aus dem Privacy-Enhanced-Mail-Bestreben (PEM) der IETF. RFC 989 im Februar 1987 war die erste formale Definition; RFC 1113 im August 1989 überarbeitete sie; RFC 1421 im Februar 1993 schloss die PEM-Spezifikation einschließlich der Base64-Kodierung ab. Base64 trat in den E-Mail-Mainstream ein, als die MIME-Spezifikation (Multipurpose Internet Mail Extensions) sie übernahm: RFC 2045 im November 1996 definierte Base64 als Standardkodierung für binäre E-Mail-Anhänge, weshalb jedes PDF und jedes Bild, das Sie jemals an eine E-Mail angehängt haben, als Base64 durch das Netz reiste. Die aktuelle kanonische Spezifikation ist RFC 4648 („The Base16, Base32, and Base64 Data Encodings"), veröffentlicht im Oktober 2006 von Simon Josefsson, die RFC 3548 (Juli 2003) ablöste und die verschiedenen Base16- / Base32- / Base64-Familien-Kodierungen in einem Dokument vereinigte. RFC 4648 ist die Spec, die jede moderne Base64-Implementierung anstrebt.

URL-safe Base64, warum zwei Zeichen getauscht werden

Das Standardalphabet von Base64 verwendet + und /, beides reservierte Zeichen in URLs. + in einem URL-Query-String bedeutet typischerweise „Leerzeichen" (form-encoded-Konvention); / ist der Pfad-Separator. Standard-Base64 in eine URL zu setzen bedeutet, beide percent-encodieren zu müssen, was die Zeichenkette weiter aufbläht und hässlich macht. RFC 4648 §5 definiert eine URL-safe-Variante: ersetze + durch - (Bindestrich-Minus) und / durch _ (Unterstrich). Manchmal Base64URL oder base64url genannt. Das Ergebnis ist eine Zeichenkette, die direkt in URLs passt, ohne weiteres Escapen, genau das, was JWT (JSON Web Tokens), OAuth-state-Parameter, WebAuthn-Credential-IDs und die meisten modernen Web-APIs verwenden. Manche Implementierungen lassen auch das abschließende =-Padding weg, weil die Länge sich aus dem nächsten Feld implizit ergibt. Die punktgetrennte Drei-Teil-Struktur eines JWT (Header.Payload.Signatur) besteht aus drei Base64URL-kodierten Segmenten; wer schon einmal ein JWT von Hand dekodiert hat, hat die Zeichen - und _ gesehen, die es als Base64URL und nicht als Standard-Base64 ausweisen.

Die Base-N-Familie, Base16, Base32, Base58, Base85

Base64 ist nicht die einzige Binär-zu-Text-Kodierung. Base16 (hex) nutzt 16 Zeichen (0-9 und A-F), 100 % Größenausdehnung (jedes Byte wird zu 2 Hex-Zeichen), aber trivial lesbar und der universelle Default für Hash-Ausgaben, Datei-Prüfsummen und Maschinenkennungen. Base32 (RFC 4648, auch Crockfords Variante) nutzt 32 Zeichen, mit Sorgfalt darauf bedacht, visuell mehrdeutige Paare wie 0/O und 1/I/L auszuschließen; 60 % Ausdehnung; verwendet in TOTP-Geheimschlüsseln, ULIDs und Tor-Onion-Adressen. Base58 ist Bitcoin-kanonisch: 58 Zeichen, die leicht zu verwechselnden 0/O/I/l ausschließend, plus die Standard-Base64-Sonderzeichen +/=. Bitcoin-Adressen, Solana-Adressen und viele Crypto-Wallet-Kennungen verwenden Base58Check (Base58 plus eine 4-Byte-Prüfsumme). Base85 / Ascii85 packt mehr Dichte (4 Bytes als 5 Zeichen kodierend, nur 25 % Ausdehnung), nutzt aber ein Alphabet mit URL-unsicherer Interpunktion; Adobes PostScript- und PDF-Formate verwenden Base85 intern für eingebettete Binärdaten. Der allgemeine Kompromiss: mehr Zeichen im Alphabet bedeuten weniger Ausdehnung, aber einen eingeschränkteren Zeichensatz; weniger Zeichen bedeuten sicherer transportierbar, aber größere Ausgabe.

Häufige Einsatzzwecke für Base64

• E-Mail-Anhänge (MIME). RFC 2045 seit 1996. Jedes PDF, jedes Bild und jedes Dokument, das Sie an eine E-Mail angehängt haben, reiste als Base64 durchs Netz, weil SMTP ursprünglich ein 7-Bit-sauberes Textprotokoll war, das mit rohem Binär nicht umgehen konnte.
• data:-URIs in HTML/CSS. data:image/png;base64,iVBORw0KGgo... bettet ein kleines Bild direkt in HTML oder ein CSS-Stylesheet ein und beseitigt eine HTTP-Anfrage. Nützlich für Icons unter ~10 KB; kontraproduktiv bei größeren Bildern, weil die 33 % Base64-Ausdehnung den eingesparten HTTP-Request-Overhead übersteigt.
• Binärdaten in JSON-Payloads. JSON ist per Spec rein textuell, es gibt keine Möglichkeit, rohe Bytes in einen JSON-Wert zu setzen. APIs, die Bilder, PDFs oder anderes Binär übertragen müssen, betten es als Base64-Strings in ein JSON-Feld ein. Stripes Webhook-Payloads, Twilios MMS-APIs und viele AI-Vision-Endpunkte verwenden dieses Muster.
• JWT (JSON Web Tokens). Die drei punktgetrennten Teile eines JWT (Header.Payload.Signatur) sind alle Base64URL-kodiert. Die JWT-Spec (RFC 7519, Mai 2015) baut auf JOSE auf (RFC 7515-7518, ebenfalls Mai 2015), die alle Base64URL durchgehend vorschreiben.
• OAuth und OpenID Connect. Der state-Parameter, PKCE-Code-Verifier, ID-Tokens und Access-Tokens verwenden in vielen Implementierungen Base64URL.
• HTTP Basic Authentication. Der Header Authorization: Basic dXNlcjpwYXNz trägt Base64(Benutzername:Passwort). Hinweis: das ist Kodierung für den Transport, KEINE Verschlüsselung, Basic Auth über reines HTTP legt Anmeldedaten im Klartext jedem offen, der das Netz beobachtet. Immer mit HTTPS kombinieren.
• Subresource Integrity (SRI). Das Attribut integrity="sha384-..." auf <script>- und <link>-Tags trägt einen Base64-kodierten Hash des erwarteten Dateiinhalts; Browser prüfen, dass die heruntergeladene Datei übereinstimmt, bevor sie ausgeführt wird.
• SVG-in-CSS-Hintergründe. background-image: url("data:image/svg+xml;base64,...") bettet ein SVG direkt in ein Stylesheet ein. Die Base64-Form wird manchmal gegenüber der URL-encoded-Form bevorzugt (die das SVG lesbar lässt, aber andere Escape-Regeln verwendet).

Kodierung ist keine Verschlüsselung, ein häufiger Sicherheitsfehler

Base64 bietet null Sicherheit. Die Kodierung ist von jedem in Millisekunden vollständig umkehrbar, das Alphabet ist öffentlich, der Algorithmus ist trivial, und jeder Browser oder Einzeiler-CLI-Befehl kann sie dekodieren. Trotzdem ist „in Base64 kodierte sensible Daten" eines der am häufigsten zitierten Beispiele in MITREs CWE-261 (Weak Encoding for Password) und taucht ständig in Sicherheitsaudits auf: API-Schlüssel, in Client-Code mit Base64 „verschleiert"; Passwörter, in Datenbank-Backups mit Base64 „kodiert"; Geheimnisse, mit Base64 „verschlüsselt", bevor sie in ein öffentliches Git-Repo committet wurden. Keines davon ist geschützt. Wenn Sie echte Vertraulichkeit brauchen, verwenden Sie echte Verschlüsselung: AES-256-GCM für symmetrisch, RSA-OAEP oder ECDH+ChaCha20-Poly1305 für asymmetrisch. Base64 ist angemessen für den Transport (Binär in textfreundliche Form zu verwandeln), aber niemals für Schutz.

Browser-Implementierung: btoa / atob und die Unicode-Falle

JavaScript stellt zwei eingebaute globale Funktionen für Base64 bereit: btoa() (binary-to-ASCII, Kodieren) und atob() (ASCII-to-binary, Dekodieren). Beide sind Legacy-APIs aus der frühen Netscape-Ära und haben eine berühmte Einschränkung: sie funktionieren nur auf Latin-1-Byte-Strings. Ein Aufruf von btoa('é') wirft InvalidCharacterError, weil der JavaScript-String 'é' einen Codepunkt oberhalb von U+00FF enthält, der nicht in ein einzelnes Byte passt. Der moderne Fix ist, zuerst per TextEncoder nach UTF-8-Bytes zu kodieren, dann das resultierende Uint8Array in einen Latin-1-String für btoa() zu konvertieren. Das Muster: btoa(String.fromCharCode(...new TextEncoder().encode(str))). Dekodieren rückwärts: new TextDecoder().decode(Uint8Array.from(atob(str), c => c.charCodeAt(0))). Neuere Browser stellen Uint8Array.toBase64() und Uint8Array.fromBase64() als eingebaute Methoden bereit, aber die Verbreitung ist 2026 noch im Rollout, der Polyfill über btoa/atob bleibt der Cross-Browser-Default. Für Dateien speziell ist FileReader.readAsDataURL() der einfachste Weg: legen Sie eine Datei in einen Input, der Reader gibt einen data:mime/type;base64,...-String mit allem korrekt kodiert zurück; entfernen Sie das data:-Präfix, um nur den Base64-Teil zu erhalten.

Ehrlicher Geltungsbereich: was dieses Tool tut und was nicht

Dieses Tool kodiert Text oder Dateien (bis zu 5 MB) nach Base64 und dekodiert Base64-Strings zurück zu Text oder herunterladbaren Dateien. Es verwendet standardmäßig das RFC 4648-Alphabet (mit + und /); URL-safe Base64URL (mit - und _) ist eine künftige Toggle-Funktion. UTF-8-Text wird über TextEncoder korrekt behandelt, die btoa-Latin-1-Falle ist behoben. Die 5-MB-Dateigrenze besteht, weil Base64 die Daten um 33 % aufbläht und der kodierte String vollständig im Browser-Speicher lebt; eine 5-MB-Binärdatei erzeugt ~6,7 MB Base64-Text plus den Original-Puffer, was auf jedem modernen Gerät funktioniert. Für größere Dateien sind die Standard-Alternativen die Kommandozeile base64 auf macOS/Linux (base64 -i input.bin -o output.txt), Pythons base64-Modul oder Node.js Buffer.from(data).toString('base64'). Dieses Tool behandelt nicht: Streaming-Base64 (Datei-stückweise-Kodierung für Dateien größer als der Arbeitsspeicher); die URL-safe-Variante in dieser Version (geplant); auch nicht MIME-quoted-printable-Kodierung (ein anderes RFC-2045-Schema für textbasierte E-Mail-Inhalte).

Datenschutz: warum Browser-only zählt

Base64 ist keine Verschlüsselung, aber die Daten, die kodiert werden, sind oft sensibel: API-Schlüssel, die Sie in eine Config-Datei einbetten, Zertifikate, die Sie für den Transport kodieren, interne Screenshots, die Sie als data-URIs in Dokumentation einbetten, oder PDF-Belege, die Sie für einen Kunden kodieren. Serverseitige Encoder sehen Ihre Eingabe. Dieses Tool läuft komplett in Ihrem Browser per JavaScript, prüfen Sie im Network-Tab der DevTools beim Klick auf Encode, oder schalten Sie die Seite nach dem Laden offline (Flugmodus), das Tool funktioniert weiter. Sicher zum Kodieren von API-Anmeldedaten, PII-Screenshots, internen Dokumenten oder beliebigen Daten, die Sie nicht auf der Festplatte eines Fremden kopiert sehen wollen.

Häufig gestellte Fragen

Ist Base64 sicher?

Nein. Base64 ist Kodierung, keine Verschlüsselung. Jeder kann eine Base64-Zeichenkette dekodieren. Verwenden Sie Base64 niemals zum Schutz sensibler Daten, nutzen Sie richtige Verschlüsselung (AES, RSA) für Sicherheit.

Warum macht Base64 Dateien größer?

Base64-Kodierung erhöht die Datengröße um etwa 33%. Drei Bytes Binärdaten werden zu vier Base64-Zeichen. Dieser Mehraufwand ist der Preis dafür, Binärdaten als Text übertragen zu können.

Kann ich Dateien kodieren?

Ja! Ziehen Sie eine beliebige Datei auf den Encoder oder klicken Sie zum Durchsuchen. Die Datei wird in einen Base64-Data-URI umgewandelt, den Sie direkt in HTML, CSS oder JavaScript einfügen können.

Was ist der Unterschied zwischen Base64 und Base64URL?

Zwei Zeichen. Standard-Base64 (RFC 4648 §4) verwendet + und / als 62. und 63. Alphabetzeichen. URL-safe Base64URL (RFC 4648 §5) verwendet stattdessen - und _, so dass der kodierte String direkt in URLs passt, ohne Percent-Encoding. JWT, OAuth, WebAuthn und die meisten modernen Web-APIs verwenden Base64URL. Dieses Tool gibt derzeit Standard-Base64 aus; URL-safe steht auf der Liste künftiger Funktionen. Um Standard manuell in URL-safe umzuwandeln: ersetze + durch -, / durch _, optional das abschließende =-Padding entfernen.

Warum scheitert mein Unicode-Text in manchen Base64-Tools?

Weil JavaScripts Legacy-Funktion btoa() nur auf Latin-1-Byte-Strings funktioniert, ein Aufruf von btoa('é') wirft InvalidCharacterError. Viele alte browserbasierte Encoder verwenden btoa direkt ohne den UTF-8-Konvertierungsschritt, sodass jede Nicht-ASCII-Eingabe bricht. Moderner Code (und dieses Tool) kodiert Strings zuerst über TextEncoder und erzeugt eine UTF-8-Bytefolge, die btoa dann sicher kodieren kann. Die neuere eingebaute Methode Uint8Array.toBase64() behandelt UTF-8 nativ, ist aber noch nicht Baseline in allen Browsern.

Werden meine Daten irgendwohin hochgeladen?

Nein. Kodieren und Dekodieren laufen vollständig in Ihrem Browser per JavaScript. Text und Dateien überqueren niemals das Netz, prüfen Sie im Network-Tab der DevTools beim Klick auf Encode, oder schalten Sie die Seite nach dem Laden offline (Flugmodus), das Tool funktioniert weiter. Sicher für API-Anmeldedaten, PII-Screenshots, interne Config-Dateien oder beliebige Daten, die Sie nicht auf der Festplatte eines Fremden kopiert sehen wollen.

Verwandte Werkzeuge