Zum Inhalt springen

Bild zu Base64

Bild als Data URI (Base64) konvertieren - mit kopierbaren CSS- und HTML-Snippets. Oder Data URI einfügen für Vorschau.

Läuft in deinem Browser

Zwei Richtungen in einem Tab. Encode: Bild ablegen, `data:image/...;base64,...` mit kopierbaren CSS- und HTML-Snippets erhalten. Decode: Data URI einfügen, anzeigen, als normales Bild herunterladen. Nichts verlässt den Browser.

Bild hier ablegen oder klicken zum Auswählen
PNG, JPG, WebP, AVIF, GIF, SVG, BMP

So funktioniert's

  1. Pick the direction

    Encode (image → base64) or decode (base64 → image) via the tab switch.

  2. Drop or paste

    Encode: drag a PNG / JPG / WebP / SVG. Decode: paste a `data:image/...` Data URI string.

  3. Copy the snippet you need

    Three ready snippets: raw Data URI, CSS `background-image: url(...)`, HTML `<img src='...'>`.

Was ist das?

Base64 is a text encoding for binary data - every 3 bytes become 4 ASCII characters drawn from `A-Za-z0-9+/`. When prefixed with `data:image/png;base64,` (or another MIME type) the result is a Data URI: a self-contained reference to an image that browsers, CSS engines and HTML parsers all dereference inline. The trade-off is a ~33 % size penalty in exchange for skipping the HTTP request.

Wann verwenden

Embedding small SVG icons in a CSS module, including a one-shot background pattern in an HTML email, inlining a logo in a build-time-generated PDF, bundling test fixtures in unit tests, or generating an OG image dynamically and serving it as a Data URI. Anywhere you'd otherwise need an extra HTTP request for a tiny asset.

Häufige Fehler

Inlining a marketing-hero photo and tanking the HTML's parsing time. Forgetting to URL-encode the `+`, `/` and `=` characters when putting the Data URI inside another URL. Pasting a Data URI without the `data:image/png;base64,` prefix (browsers reject it). And inlining a large asset that the browser could otherwise cache across pages.

FAQ

When should I inline an image as base64?
When the image is tiny (under ~2 KB), only used once, and the extra HTTP request would be a measurable share of the page weight. Common cases: an SVG icon embedded in a CSS module, a one-off background pattern in an email template, an inline logo for a static documentation page.
When should I NOT inline?
Big images. Anything over ~10 KB is better served as a separate file because (a) the browser can cache it across pages, (b) base64 adds ~33 % overhead, and (c) inline content can't be lazy-loaded. Marketing hero images and product photos are almost never good base64 candidates.
What's the size overhead?
Roughly 4/3 (33 % bigger). 3 bytes of binary become 4 base64 characters. So a 12 KB PNG becomes ~16 KB once encoded. Gzip recovers some of that on the wire but not all.

Mehr in dieser Kategorie