Bild-Base64-Umwandlungstool
Bilder und Base64-Kodierung gegenseitig konvertieren, Drag & Drop Upload und Echtzeitvorschau unterstützt
Bild hierher ziehen oder klicken zum Auswählen
JPG, PNG, GIF, WebP, SVG und andere Formate unterstützt
Was ist Base64-Bildkodierung?
Der Image-Base64-Konverter wandelt Bilddateien in Base64-Text oder Data-URLs um und kann solche Zeichenketten wieder als Bild darstellen. Das ist praktisch für kleine Icons, Platzhalter, E-Mail-Vorlagen, CSS-Hintergründe oder Tests, bei denen keine separate Bilddatei bereitgestellt werden soll. Base64 macht Daten jedoch ungefähr ein Drittel größer und ist für große Fotos, viele Assets oder langfristige Speicherung meist ungeeignet. Das Werkzeug hilft beim schnellen Umwandeln und Prüfen, ersetzt aber keine bewusste Entscheidung zwischen eingebetteten Daten, CDN-Dateien und normalen Bild-URLs im späteren Produktivbetrieb. Vor Veröffentlichung oder Abgabe sollte die Ausgabedatei geöffnet und auf Lesbarkeit, Zuschnitt, Auflösung und fehlende Inhalte geprüft werden.
So geht's
So geht's
- Bild per Drag & Drop oder per Klick hochladen, Typ und Maße werden automatisch erkannt
- Ausgabeformat wählen: Data URL (direkt im Code nutzbar) oder reines Base64
- Auf die Schaltfläche „Kopieren' klicken, um das kodierte Ergebnis an der gewünschten Stelle einzufügen
- Für die Rückkonvertierung den Base64-String einfügen und auf „Konvertieren' klicken, um das Bild herunterzuladen
Base64 zu Bild
- Data URL oder reinen Base64-String in das Eingabefeld einfügen und konvertieren, um das decodierte Bild vor dem Herunterladen in der Vorschau anzuzeigen.
- Wenn die Decodierung fehlschlägt, prüfen Sie, ob der Base64-Text vollständig ist und ob das Präfix data:image/... korrekt gebildet wurde.
Bild zu Base64
- Wählen Sie Data URL, wenn das Ergebnis direkt in HTML oder CSS eingefügt werden soll, und reines Base64, wenn ein anderes System den MIME-Typ bereits separat speichert.
- Halten Sie Base64-Bilder klein. Große Bilder erhöhen die Textgröße um etwa ein Drittel und können HTML-, CSS- oder JSON-Payloads schwerer wartbar machen.
Anwendungsfälle
Technisches Prinzip
Ein Base64-kodiertes Bild ist eine Data URI gemäß RFC 2397: Das Schema-Präfix data:, der MIME-Typ wie image/png, die Zeichenfolge ;base64 und dann die Nutzlast aus dem 64-Zeichen-Alphabet A-Z, a-z, 0-9, +, /, wobei = als abschließendes Padding dient. Die Kodierung nimmt den Binärstrom jeweils drei Bytes zusammen und gibt vier Zeichen aus, sodass die Nutzlast um den festen Faktor 4/3 (etwa 33 %) wächst, zuzüglich ein oder zwei Padding-Zeichen, wenn die Byteanzahl kein Vielfaches von drei ist. Im Browser beginnt die Kodierung mit FileReader.readAsDataURL, der die Datei durch dieselbe Pipeline leitet und die vollständige data: URL liefert, die direkt in ein <img src> oder eine CSS-Hintergrundbild-url() eingefügt werden kann. Die reinen btoa- und atob-Primitive arbeiten auf bereits binären Nutzlasten (nur latin-1, daher müssen Binärbytes über Uint8Array konvertiert werden). Die Rückdecodierung in ein sichtbares Bild erfolgt über atob in ein Uint8Array, dann in einen Blob mit dem ursprünglichen MIME-Typ, und das URL.createObjectURL-Handle wird zu einer normalen HTTP-abrufbaren Ressource. Der praktische Kompromiss betrifft nicht die Bandbreite, sondern das Caching. Jedes Vorkommen der Nutzlast wird dort dupliziert, wo HTML, CSS oder JSON erscheint, sodass die Ressource nicht separat gecacht werden kann, keinen eigenen ETag erhält und bei jedem übergeordneten Dokument erneut heruntergeladen wird. Strikte Content-Security-Policy-Regeln blockieren außerdem data: URIs, sofern 'data:' nicht explizit unter img-src oder style-src aufgeführt ist. Seit HTTP/2 Multiplexing verfügbar ist, schlägt das Inline-Einbinden kleiner Icons selten eine separate Anfrage, daher gilt als moderne Faustregel: Nur unter etwa 2 KB inline einbinden, Hero-Bilder und wiederverwendbare Sprites als cachebare Dateien belassen.
- Data-URI-Schema: RFC-2397-Format data:[<mime>][;base64],<payload>; das Komma ist erforderlich und die häufigste Fehlerquelle beim Kopieren und Einfügen.
- Kodierungs-Overhead: 3 Binärbytes werden zu 4 ASCII-Zeichen, sodass die Nutzlast um den Faktor 4/3 (ca. 33 %) wächst, zuzüglich bis zu 2 '='-Padding-Zeichen.
- Browser-APIs: FileReader.readAsDataURL für Dateien; btoa/atob für bereits textbasierte Nutzlasten (nur latin-1, daher ist für Binärdaten eine Uint8Array-Brücke nötig).
- Decodierungspfad: atob → Uint8Array → new Blob([buf], {type}) → URL.createObjectURL liefert eine normale abrufbare Asset-URL statt eines eingefrorenen Strings.
- CSP-Falle: Eine strenge img-src- oder default-src-Richtlinie blockiert data:, sofern das Schlüsselwort nicht explizit aufgeführt ist, was Inline-Bilder in der Produktion stillschweigend zerbricht.
- Caching-Kompromiss: Inline-Daten haben keinen eigenen ETag oder Cache-Eintrag, daher schlägt HTTP/2 Multiplexing das Inline-Einbinden bei allem über etwa 2 KB.
Beispiele
Verwendung in HTML
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII=" alt="1x1 transparentes Pixel" width="16" height="16" />Verwendung in CSS
.icon-search {
width: 16px;
height: 16px;
background-image: url('data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCAxNiAxNiI+PHBhdGggZD0iTTYgMmE0IDQgMCAxIDAgMi4yNCA3LjMzbDMuMjEgMy4yMSAxLjQyLTEuNDItMy4yMS0zLjIxQTQgNCAwIDAgMCA2IDJ6Ii8+PC9zdmc+');
background-size: contain;
}Übertragung über JSON-API
POST /api/v1/avatar
Content-Type: application/json
{
"userId": 10086,
"avatar": {
"mimeType": "image/png",
"data": "iVBORw0KGgoAAAANSUhEUgAAAAUA..."
}
}
// Hinweis: Base64 vergrößert die Nutzlast um ca. 33 %; bei Dateien > 100 KB besser multipart/form-data verwenden.FAQ
Wird das Bild hochgeladen?
Nein. Das Bild wird mit der FileReader API gelesen und in deinem Browser Base64-kodiert. Die Daten verlassen dein Gerät nicht. Du kannst das im Netzwerk-Tab während der Konvertierung bestätigen.
Warum ist der Base64-String etwa 33 % länger als die Datei?
Base64 stellt 3 Eingabe-Bytes als 4 ASCII-Zeichen dar, also encoded_size = ceil(file_size / 3) * 4. Das sind etwa 33 % Mehraufwand - der Preis dafür, Binärdaten als druckbaren Text darzustellen.
Wie verwende ich das Ergebnis in HTML oder CSS?
Nutze eine Data-URI: <img src="data:image/png;base64,..."> in HTML oder background-image: url(data:image/png;base64,...) in CSS. Die Seite generiert die vollständige data:-URI für dich. Praktisch für winzige Inline-Assets, bläht aber die HTML-/CSS-Dateigröße auf und umgeht das Browser-Bild-Caching.
Wo liegt die Größengrenze zwischen Inlining und Verlinken?
Unter ~5 KB lohnt sich Inlining meistens (spart einen HTTP-Request). Darüber sollte die Datei aus Caching-Gründen ein eigenes Asset sein. Über ~50 KB bläht Inlining dein HTML deutlich auf. Build-Tools setzen unterschiedliche Schwellen; webpack hat 8 KB als Default.
Kann ich einen Base64-String wieder zurück in ein Bild dekodieren?
Ja. Füge eine data:-URI oder rohes Base64 (mit image/* MIME-Typ) ein, und die Seite rekonstruiert das Bild und bietet es zum Download an. Praktisch, wenn du ein eingebettetes Bild im Quellcode findest und die Originaldatei haben möchtest.
Werden SVG und animierte GIFs unterstützt?
Ja. SVG kann direkt kodiert werden oder über URL-kodierten Text (was bei SVG-XML kürzer ist als Base64). Animierte GIFs werden zu einem einzigen Base64-String kodiert; das Ergebnis bleibt animiert. WebP, AVIF und andere moderne Formate funktionieren genauso.
Soll ich große Fotos für E-Mails Base64-kodieren?
E-Mail selbst MIME-kodiert Anhänge sowieso in Base64, du musst sie also nicht vorab kodieren. Einen Base64-String in den Mail-Text zu kleben, macht die Nachricht nur größer und für die meisten Clients unlesbar. Häng die Datei normal an.