Bild-zu-Base64

Der Image-to-Base64-Konverter verwandelt eine Bilddatei in eine Base64-kodierte Data-URI, die Sie direkt in HTML, CSS, JSON oder Quellcode einfügen können. Er akzeptiert PNG, JPEG, GIF, WebP, SVG und BMP, zeigt genau an, um wie viel die Kodierung die Datei aufbläht, und läuft vollständig im Browser – das Bild wird niemals hochgeladen.

Verwendung

1. Ziehen Sie ein Bild auf die Upload-Fläche oder klicken Sie, um eine Datei vom Typ PNG, JPEG, GIF, WebP, SVG oder BMP auszuwählen.
2. Die Vorschau erscheint sofort, und das Tool liest die Datei mit der FileReader API ein.
3. Prüfen Sie die vier Kennzahlen: MIME-Typ, Originalgröße, Base64-Größe und den prozentualen Zuwachs.
4. Kopieren Sie die vollständige Data-URI mit einem Klick, einschließlich Präfix.
5. Fügen Sie sie überall dort ein, wo normalerweise eine URL steht – ein img src, ein CSS-background-image oder ein JSON-Feld.

Die Platzierung ist entscheidend. In HTML wandert die Zeichenkette direkt in das Attribut: <img src="data:image/png;base64,iVBORw0KGgo...">. In CSS steht sie innerhalb eines quotierten url(): background-image: url("data:image/svg+xml;base64,PHN2Zy...");. In JSON ist sie schlicht ein String-Wert. Behalten Sie das Semikolon zwischen MIME-Typ und base64; entfernen Sie es, wird die URI ungültig und das Bild scheitert stillschweigend. In CSS sollten Sie den Wert immer in Anführungszeichen setzen, denn eine unquotierte Data-URI kann an einer ) innerhalb einer SVG-Nutzlast zerbrechen.

Die Rechnung hinter den 33 % Aufschlag

Base64 verwendet ein Alphabet aus 64 Zeichen, damit das Ergebnis gefahrlos in reine Textkanäle eingefügt werden kann. Jede 3 Eingabebytes werden auf 4 Ausgabezeichen abgebildet, woraus das feste Verhältnis folgt:

encoded length = ceil(bytes / 3) × 4

Das Tool rechnet rückwärts, um die Originalgröße zu schätzen: Es nimmt die Länge der Base64-Nutzlast, multipliziert sie mit 3/4 und zieht 1 oder 2 Zeichen für eventuelles abschließendes =-Padding ab. Deshalb stimmt die angezeigte „Originalgröße“ fast exakt mit der Datei überein. Der sichtbare Aufschlag beträgt also 33,3 % plus das kurze Präfix – data:image/png;base64, sind beispielsweise 22 zusätzliche Zeichen.

Padding entsteht immer dann, wenn die Byte-Anzahl nicht durch drei teilbar ist. Ein übrig gebliebenes Byte erzeugt zwei Zeichen plus ==; zwei Restbytes ergeben drei Zeichen plus =. Eine Nutzlast, deren Länge ein Vielfaches von drei ist, endet ganz ohne Padding. Ohne diese Korrektur würde die kodierte Zeichenkette geringfügig größer erscheinen als sie ist; die Subtraktion hält die Schätzung ehrlich.

Praxisbeispiele

Quelldatei	Base64-Nutzlast	Angezeigter Zuwachs	Ungefähre Data-URI
1 KB großes Symbol	~1,37 KB	~33,3 %	~1,39 KB mit Präfix
10 KB großes Logo	~13,7 KB	~33,3 %	~13,7 KB mit Präfix
100 KB großes Foto	~133 KB	~33,3 %	~133 KB mit Präfix

Das Verhältnis ist konstant; nur die absoluten Bytes ändern sich. Ein 4 KB großes PNG und ein 4 MB großes PNG wachsen beide um ein Drittel.

Wann eine Inline-Data-URI gewinnt

• Symbole, Favicons und kleine Logos, die sonst auf jeder Seite eine zusätzliche HTTP-Anfrage kosten würden.
• Einzelne HTML-Dokumente und Offline-Demos, die nicht von externen Assets abhängen dürfen.
• JSON-Nutzlasten, die ein Vorschaubild ohne Multipart-Upload transportieren müssen.
• E-Mail-Vorlagen, bei denen bekannt ist, dass der Client Data-URIs darstellt.
• CSS-background-image-Regeln für winzige dekorative Texturen.

Wann sie verliert

Jede Data-URI ist in das Dokument eingebettet und kann daher nicht separat zwischengespeichert werden. Taucht dasselbe Symbol auf zwanzig Seiten auf, lädt der Browser diese Bytes zwanzigmal statt einmal. Die Kodierung bläht zudem jedes Asset um ein Drittel auf, und eine sehr große Data-URI in einem Stylesheet blockiert das Rendering während des Parsens. Für Bilder über etwa 10 KB ist eine externe Datei mit passenden Cache-Headern fast immer der bessere Tausch.

Die Rechnung macht den Punkt deutlich. Ein 6 KB großes Symbol, das in ein gemeinsames Stylesheet eingebettet ist, wird einmal geladen; dasselbe Symbol, das in das HTML jeder Seite eingefügt wird, wird zwanzigmal geladen – 120 KB Übertragung, wo eine externe Datei beim ersten Laden 6 KB und danach nichts übertragen würde. Wiederholen Sie das über ein kleines Symbol-Set, wächst die Summe schnell. Die Faustregel lautet: Nur einbetten, wenn das Bild winzig ist und eine separate Anfrage mehr kosten würde als der Aufschlag.

Genauigkeit und Grenzen

• Die Größenangaben stammen aus der dekodierten Base64-Länge, nicht aus einer frischen Byte-Zählung der Datei, sodass sie bei ungewöhnlich gepolsterten Dateien um ein oder zwei Byte abweichen können.
• Das Tool kodiert; es komprimiert nicht. Ein PNG bleibt ein PNG, ein JPEG bleibt ein JPEG.
• Inline-Bilder werden nicht automatisch optimiert, daher lohnt es sich, ein großes Foto vor der Kodierung durch einen Kompressor zu schicken.
• Das Präfix muss den korrekten MIME-Typ verwenden. Ein als image/jpeg bezeichnetes PNG wird von Browsern wegen des Byte-Sniffings oft trotzdem dargestellt, aber strikte Werkzeuge lehnen es möglicherweise ab.
• Sehr lange Zeichenketten sind umständlich zu speichern und zu prüfen. Editoren werden langsam, und manche Build-Pipelines schneiden Werte jenseits einiger hundert Kilobyte ab.
• Das Kopieren in die Zwischenablage nutzt die moderne Clipboard API mit einem Fallback für ältere Browser; in manchen Browsern erfordert der Fallback eine Nutzergeste.

Verwandte Tools

• Base64 Encoder/Decoder — beliebigen Text kodieren und dekodieren, nicht nur Bilder.
• Bildkompressor — das Bild vor dem Einbetten verkleinern.
• Bildformat-Konverter — das Format vor der Kodierung wechseln.