Base64-String oder Data URI

Anleitung

1. Fügen Sie einen Base64-kodierten Bild-String in das Eingabefeld ein. Er kann das data:image/...-Präfix oder nur die rohen Base64-Daten enthalten.
2. Klicken Sie auf Bild dekodieren, um es in der Vorschau zu sehen.
3. Klicken Sie auf Bild herunterladen, um es als PNG-Datei zu speichern.

Häufig gestellte Fragen

Welche Base64-Formate werden unterstützt?

Sie können einen reinen Base64-String einfügen (das Tool erkennt das Format automatisch) oder eine vollständige Data URI wie data:image/png;base64,iVBOR.... Unterstützte Bildtypen sind PNG, JPEG, WebP, GIF, BMP und SVG.

Gibt es eine Größenbeschränkung?

Es gibt keine harte Grenze, aber sehr große Base64-Strings (über 5–10 MB) können je nach Gerät langsam zu verarbeiten sein.

Wie kodiere ich ein Bild in Base64?

Verwenden Sie unser Bild zu Base64 Konverter-Tool, einfach ein Bild per Drag-and-Drop ablegen, um seinen Base64-String zu erhalten.

Was Base64 eigentlich ist

Base64 ist ein Binär-zu-Text-Kodierungsschema, definiert in RFC 4648 (Oktober 2006). Es verwendet ein 64-Zeichen-Alphabet, A-Z, a-z, 0-9, plus + und /: um beliebige Bytes als druckbares ASCII darzustellen. Aus je drei Bytes binärer Eingabe werden genau vier Zeichen Ausgabe, weil das kleinste gemeinsame Vielfache von 6 Bit (ein Base64-Zeichen) und 8 Bit (ein Byte) 24 ist. Dieses Verhältnis von vier zu drei ist auch der Grund, warum eine Base64-kodierte Datei rund 33 % größer ist als das ursprüngliche Binärformat.

Wenn die Eingabelänge kein Vielfaches von drei ist, füllt Base64 mit = auf, sodass die Ausgabe immer ein Vielfaches von vier Zeichen ist: ein einzelnes übrig bleibendes Byte erzeugt zwei Zeichen plus ==; zwei übrig bleibende Bytes erzeugen drei Zeichen plus =. Manche Encoder entfernen die Auffüllung, daher muss ein robuster Decoder erneut auffüllen, bevor er den String an atob() übergibt.

RFC 4648 definiert außerdem eine URL-sichere Variante (manchmal base64url genannt), die + durch - und / durch _ ersetzt. JWTs verwenden sie. Dieser Decoder normalisiert beide Alphabete, sodass Sie nicht darüber nachdenken müssen, welches Ihnen vorliegt.

Das Data-URI-Schema

RFC 2397 (August 1998) definiert das data:-URL-Schema. Die vollständige Grammatik lautet:

data:[<mediatype>][;base64],<data>

Ein typisches Inline-PNG sieht so aus: data:image/png;base64,iVBORw0KGgo…. Das Token ;base64 ist ein Marker (beachten Sie das Fehlen eines =-Zeichens), der dem Browser mitteilt, die Nutzlast aus Base64 zu dekodieren, statt sie als prozentkodierten Text zu behandeln. Wenn Sie ;base64 weglassen, werden die Daten als URL-kodierter Text interpretiert. Wenn Sie den Medientyp vollständig weglassen, verwendet die Spezifikation standardmäßig text/plain;charset=US-ASCII.

Dieser Decoder akzeptiert beide Formen: Fügen Sie ein vollständiges Data-URI oder nur die Base64-Nutzlast ein. Wenn nur die Nutzlast angegeben wird, wird das Format aus den ersten dekodierten Bytes erkannt, siehe unten.

Wie das Format erkannt wird

Wenn Sie einen rohen Base64-String ohne data:image/…-Präfix einfügen, lässt sich die Art des Bildes nur erkennen, indem man die ersten dekodierten Bytes betrachtet, jedes gängige Bildformat beginnt mit einer erkennbaren Signatur, formell „magische Zahl“ genannt. Browser führen genau dieselbe Prüfung durch, wenn sie MIME-Typen erschnüffeln (das Verfahren steht im WHATWG-MIME-Sniffing-Standard). Die Abkürzung ist, dass sich diese Signaturen in vorhersehbare Base64-Präfixe übersetzen:

Format	Erste Bytes (Hex)	Base64-Präfix
PNG	89 50 4E 47 0D 0A 1A 0A	iVBORw0KGgo
JPEG	FF D8 FF	/9j/
GIF89a	47 49 46 38 39 61	R0lGODlh
WebP	52 49 46 46 … 57 45 42 50	UklGR
BMP	42 4D („BM“)	Qk
SVG (XML-Text)	beginnt mit <?xml oder <svg	PD94bWwg oder PHN2Zw

Die Signatur von PNG gehört zu den raffinierteren im Format-Zoo. Das Byte 89 hat das höchstwertige Bit gesetzt, sodass ein nur 7-Bit-fähiges Mail-Relay es sichtbar beschädigt. Die nächsten drei Bytes ergeben PNG in ASCII, sodass ein Mensch, der head auf der Datei ausführt, sie erkennen kann. Dann folgen ein DOS-Zeilenende (0D 0A), ein MS-DOS-Ctrl-Z, das den alten TYPE-Befehl davon abhält, weiterzudrucken, und ein Unix-Zeilenvorschub (0A), gemeinsam erkennen sie jeden gängigen Transportweg, der Zeilenenden „hilfsbereit“ umschreibt.

Woher Base64-Bilder kommen

Die meisten Menschen, die auf einem Werkzeug wie diesem landen, suchen einen Fehler. Häufige Situationen:

• JSON-API-Antworten. JSON hat keinen nativen Binärtyp, daher liefern APIs Bilder, signierte PDFs, Profilbilder und hochgeladene Screenshots als Base64-Strings in JSON-Feldern. Wenn Sie den Wert hier einfügen, sehen Sie, was er tatsächlich war.
• CSS und gebündelte Assets. Webpack und Vite haben einen Schwellenwert für kleine Assets (Vite verwendet standardmäßig 4 KB), der kleine Bilder automatisch als Data-URIs in das gebündelte CSS oder JS einbettet. Bei der Fehlersuche „Woher kommt dieses Symbol?“ landet das Data-URI hier.
• HTML-E-Mail-Signaturen. Gmail, Outlook und Apple Mail betten Signaturbilder als Data-URIs ein, damit das Bild das Weiterleiten übersteht. Designer brauchen manchmal das ursprüngliche Logo zurück.
• CMS- und Notion-Exporte. WordPress-XML-Exporte, Notion-Exporte und Confluence-Backups betten Vorschaubilder inline als Base64 ein, um den Export eigenständig zu halten.
• QR-Codes und Signaturfelder. Browser-Bibliotheken, die QR-Codes erzeugen (qrcode.js) oder handschriftliche Unterschriften erfassen (signature_pad), geben ihre Ausgabe typischerweise als data:image/png;base64,…-String aus.
• Serverseitige PDF-Erzeugung. Werkzeuge wie Puppeteer, openhtmltopdf und iText akzeptieren HTML mit Inline-Data-URIs. Wenn ein Logo im gerenderten PDF „nicht erscheint“, ist das Dekodieren des URI der schnellste Weg, um zu sehen, ob die Bytes überhaupt ein Bild waren.

Sollten Sie Bilder als Base64 einbetten?

Die Abwägung war früher interessanter. Unter HTTP/1.1 war jedes Bild eine separate blockierende Anfrage, und das Einbetten eines winzigen Symbols konnte einen echten Roundtrip einsparen. Unter HTTP/2 und HTTP/3 hat sich der Fall stark verengt. Ehrliche Zusammenfassung:

Sie gewinnen: null zusätzliche HTTP-Anfragen, atomare Auslieferung und eigenständige Artefakte, die ohne externe Abhängigkeiten funktionieren (Einzeldatei-Demos, E-Mail, serverseitig gerenderte PDFs).

Sie verlieren: Der Browser kann ein eingebettetes Data-URI nicht separat zwischenspeichern, sodass dasselbe Bild auf zehn Seiten mit jeder HTML-Antwort erneut heruntergeladen wird. Das kodierte Asset ist rund 33 % größer als das binäre Äquivalent. CDNs können seitenübergreifend eingebettete Bilder nicht deduplizieren. Bildoptimierungs-Pipelines (Cloudinary, Vercel, Next.js <Image>) können eingebettete Assets nicht prüfen, komprimieren, skalieren oder in modernen Formaten wie AVIF oder WebP ausliefern. Der Browser muss außerdem zuerst das Base64 und dann das Bild dekodieren, was bei jedem Rendern zusätzliche CPU bedeutet.

Vernünftige Faustregeln: Betten Sie Bilder ein, die kleiner als etwa 4 KB sind und nur an einer Stelle verwendet werden, Einzelpixel-Platzhalter sowie Bilder, die innerhalb einer eigenständigen Datei mitreisen müssen. Betten Sie nichts ein, was auf mehr als einer Seite verwendet wird, nichts, was größer als etwa 4 KB ist, nichts, was per Lazy Loading geladen werden sollte, und nichts, was von einer Formataushandlung profitiert.

Sicherheit: was Base64 nicht leistet

Base64 ist Kodierung, keine Verschlüsselung. RFC 4648 §12 warnt ausdrücklich, dass es Daten „visuell verbirgt“, aber „keine rechnerische Vertraulichkeit“ bietet, jeder kann sie sofort dekodieren. Kodieren Sie Passwörter oder API-Schlüssel nicht mit Base64 in dem Glauben, das sei eine Sicherheitsmaßnahme.

Zwei Sicherheitsdetails, die man kennen sollte:

• Die Top-Level-Navigation zu data:-URLs ist blockiert in modernen Browsern (das Öffnen in einem neuen Tab funktioniert nicht), um Phishing-Angriffe einzudämmen, die gefälschte Anmeldeseiten aus Data-URIs gerendert haben. Die Nutzung als Subressource (<img src="data:…">, CSS url(data:…)) ist weiterhin erlaubt.
• SVG ist ein Sonderfall. SVG ist XML, und SVG-Dokumente können <script>-Elemente und Event-Handler enthalten. Das Laden eines SVG in ein <img>-Tag ist sicher (Browser führen einen Renderer mit deaktivierten Skripten aus), aber das Laden desselben SVG in <object> oder <iframe> kann beliebiges JavaScript ausführen. Dieser Decoder setzt ausschließlich <img src>, was der sichere Weg ist. Wenn Sie ein SVG aus einer nicht vertrauenswürdigen Quelle dekodiert haben, behandeln Sie die Datei wie jedes andere nicht vertrauenswürdige Dokument.

Weitere Fragen

Warum schlägt mein Base64-String mit „InvalidCharacterError“ fehl?

Drei übliche Ursachen: versprengter Leerraum oder Zeilenumbrüche aus einem Copy-and-paste (das ältere MIME-Base64-Profil bricht Zeilen bei 76 Zeichen um, was JavaScripts atob() ablehnt); URL-sicheres Base64 mit - und _ statt + und /; oder entfernte abschließende =-Auffüllung, sodass die Länge kein Vielfaches von vier ist. Dieser Decoder bereinigt Leerraum, normalisiert das Alphabet und füllt vor dem Dekodieren erneut auf, aber sehr beschädigte Strings schlagen weiterhin fehl.

Verliere ich beim Dekodieren an Qualität?

Nein. Das Dekodieren ist die exakte Umkehrung des Kodierens, Sie erhalten das ursprüngliche Bild Byte für Byte zurück. Der Download liegt in dem Format vor, das im Base64 enthalten war (PNG, JPEG, WebP, GIF, BMP oder SVG), ohne einen Neukodierungsschritt.

Was ist das größte Data-URI, das ein Browser akzeptiert?

Laut MDN liegen die aktuellen Grenzen bei rund 512 MB für Chromium und Firefox und bei rund 2 GB für Safari/WebKit. In der Praxis ist der Engpass eher Speicher und CPU als die URL-Spezifikation, Einfügungen über rund 10 MB beginnen sich auf einem typischen Laptop träge anzufühlen.

Werden Daten an einen Server gesendet?

Nein. Das Dekodieren geschieht vollständig in Ihrem Browser über die native Funktion atob() und ein Blob oder Data-URI, das einem <img>-Tag zugewiesen wird. Es wird nichts hochgeladen; die Seite funktioniert offline, sobald sie geladen ist.

Warum beginnt das Base64 jedes JPEGs mit /9j/?

Fast jede JPEG-Datei in freier Wildbahn beginnt mit den Bytes FF D8 FF (Start-of-Image-Marker, gefolgt von einem weiteren Marker-Byte). Wenn Sie drei Bytes Base64-kodieren, die alle FF sind mit einem D8 in der Mitte, teilt sich das Bitmuster 11111111 11011000 11111111 in 6-Bit-Gruppen 111111 111101 100011 111111 auf: Base64-Alphabetpositionen 63, 61, 35, 63, die /9j/ ergeben. Das vierte Zeichen variiert dann je nachdem, welcher Marker folgt (E0 für JFIF, E1 für Exif), aber die ersten drei sind universell.

Verwandte Tools