Afbeeldingen als Base64 inbedden in HTML/CSS: voor- en nadelen

Er is een techniek in webdevelopment waarbij je, in plaats van te linken naar een image-bestand met <img src="logo.png">, de eigenlijke image-bytes direct in de HTML of CSS inbedt als een Base64-string:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA..." />

Dit heet een data-URI. Het kan pagina’s sneller of trager laten laden, groter of kleiner maken, en je flink in de problemen brengen als het verkeerd wordt gebruikt.

Wat een data-URI eigenlijk is

Een data-URI is een URL die de data zelf bevat, geen pointer naar data ergens anders. Het formaat is:

data:<mime-type>;base64,<base64-encoded-data>

Voor een PNG-afbeelding:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...

Voor een SVG:

data:image/svg+xml;base64,PHN2ZyB4bWxucz0i...

Of, specifiek voor SVG, kun je Base64 overslaan en URL-gecodeerde SVG-tekst gebruiken:

data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg'>...</svg>

De browser parseert de URI, decodeert de data en rendert de afbeelding alsof hij uit een bestand was geladen.

Waarom iemand dit zou doen

Het gebruikelijke argument: het bespaart een HTTP-request. Zonder data-URI vraagt de browser image.png op, wacht op de server en downloadt de afbeelding. Met de data-URI zit alles al in de HTML.

In de dagen vóór HTTP/2 had elke request merkbare overhead. Een pagina met vijftig piepkleine iconen kon meetbaar sneller worden door die inline te zetten als data-URI’s.

De argumenten ertegen

Data-URI’s blazen het bestand op. Base64 voegt 33% overhead toe aan de ruwe bestandsgrootte. Een 1 KB-icoon inline zetten voegt ruwweg 1,3 KB toe aan je HTML. Voor één icoon prima, maar voor vijftig heb je 65 KB toegevoegd aan je HTML-payload — die gedownload en geparsed moet worden voordat er iets rendert.

Ze kunnen niet apart gecached worden. Een logo.png-bestand wordt door de browser gecached en op elke pagina hergebruikt. Een Base64-gecodeerd logo is onderdeel van elke HTML-pagina waarop het verschijnt. Eerste bezoek: geen verschil. Elk volgend bezoek: verspilde bandbreedte.

Ze blokkeren parallel downloaden. Browsers downloaden meerdere externe assets parallel. Inline data-URI’s zijn onderdeel van de HTML zelf, wat betekent dat ze concurreren met de initiële HTML-download. Is de HTML 500 KB door inline-afbeeldingen, dan blijft de pagina langer leeg.

Ze zijn lelijk in broncode. Een 200-karakter Base64-string middenin je HTML of CSS maakt code review en debugging moeilijker.

HTTP/2 en HTTP/3 maken het originele voordeel grotendeels ongedaan. Het argument “vermijd extra HTTP-requests” was sterk op HTTP/1.1, waar elke request merkbare kosten had. HTTP/2 multiplexet veel requests over één connectie met bijna nul per-request overhead. Op moderne servers zijn twintig losse image-requests niet betekenisvol trager dan één — de overhead zit in de data zelf, niet in de request.

Wanneer data-URI’s echt een goed idee zijn

Ondanks de nadelen hebben data-URI’s specifieke goede use cases.

Zeer kleine, zeer frequente iconen. Een 100-byte CSS-icoon dat veel keer op één pagina wordt gebruikt is een goede data-URI-kandidaat. De overhead is minimaal, het rendert direct, en de eerste HTTP-request die je bespaart is meer waard dan de HTML-bloat.

Achtergrondafbeeldingen in CSS die op elke pagina worden gebruikt. CSS-bestanden worden langdurig gecached. Een data-URI binnen een CSS-bestand wordt samen met de CSS gecached, dus het caching-bezwaar geldt minder sterk. Voor piepkleine achtergrondafbeeldingen — textuuroverlays, gradients die je niet met CSS kunt doen — kunnen data-URI’s in CSS schoner zijn dan losse bestanden.

E-mail-HTML. Veel e-mailclients blokkeren standaard externe afbeeldingen. Afbeeldingen inbedden als data-URI’s betekent dat ze renderen ongeacht de blokkering — maar pas op: sommige clients (Gmail, Outlook) blokkeren ook data-URI’s. Test grondig.

Offline-first webapps. Moet je app functioneren zonder netwerkverbinding, dan zorgen data-URI’s ervoor dat afbeeldingen die in de app zijn gebundeld altijd worden weergegeven. Een echte use case voor Progressive Web Apps.

Runtime gegenereerde afbeeldingen. Als je een afbeelding dynamisch genereert in JavaScript — bijv. tekenen op een <canvas> — is de natuurlijke output een Base64 data-URL. Je hoeft niet eerst naar een bestand op te slaan.

Print-stylesheets en geïsoleerde artefacten. HTML bedoeld om te printen of op te slaan als één bestand profiteert van data-URI’s, want er zijn geen aparte bestanden om je zorgen over te maken.

Wanneer data-URI’s zeker de verkeerde keuze zijn

Grote afbeeldingen. Alles boven ongeveer 10 KB (13 KB Base64-gecodeerd) is bijna altijd beter als apart bestand. De HTML-bloat is te hoog, het caching-voordeel telt te zwaar.

Afbeeldingen die veranderen. Een avatar, een header-foto, een productafbeelding — alles wat varieert. Die moeten bestanden zijn, gecached en vervangen indien nodig.

SEO-zichtbare afbeeldingen. Zoekmachines crawlen data-URI’s, maar behandelen ze als minder belangrijk dan echte bestanden. Wil je dat een afbeelding rankt in Google Images, gebruik een echt bestand met goede alt-tekst.

Afbeeldingen die meerdere keren worden gerefereerd. Als hetzelfde icoon op twaalf plekken verschijnt, betaalt een data-URI de encoderingskosten twaalf keer. Een echt bestand wordt één keer gecached.

De break-even vuistregel

Voor de meeste moderne websites op HTTP/2 of HTTP/3:

Asset-grootte	Eén keer gebruikt	Veel keer gebruikt
< 1 KB	Data-URI OK	Data-URI OK
1-5 KB	Data-URI OK	Apart bestand
5-10 KB	Marginaal	Apart bestand
> 10 KB	Apart bestand	Apart bestand

Bij twijfel: benchmark. Tools als Chrome Lighthouse en WebPageTest meten de werkelijke impact.

Een praktische workflow

Heb je besloten dat een specifieke afbeelding een goede data-URI-kandidaat is:

1. Optimaliseer eerst de afbeelding. Haal hem door een compressor — een 10 KB PNG geoptimaliseerd naar 3 KB maakt een veel betere data-URI dan de niet-geoptimaliseerde versie. Zie onze Image Compressor.

2. Converteer naar Base64. Drop het bestand in een Base64-tool. Je krijgt de Base64-string direct.

3. Bouw de data-URI. Zet data:image/png;base64, (of het passende MIME-type) vooraan de string.

4. Plak in je HTML of CSS. Voor HTML: <img src="data:...">. Voor CSS: background: url(data:...).

5. Test in meerdere browsers en e-mailclients. Ondersteuning is universeel in moderne browsers maar varieert in e-mail.

Een noot over SVG

SVG is een speciaal geval. SVG-afbeeldingen zijn tekstgebaseerd, wat betekent dat ze in HTML of CSS kunnen worden ingebed als ruwe tekst zonder Base64. Ruwe SVG is doorgaans kleiner dan Base64-gecodeerde SVG — Base64 voegt altijd 33% toe, terwijl ruwe SVG alleen kleine escape-aanpassingen nodig heeft.

/* Base64-gecodeerde SVG (groter) */
background: url('data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3...');

/* URL-gecodeerde SVG-tekst (kleiner, vaak 40%+) */
background: url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg">...');

Voor SVG specifiek: geef de voorkeur aan URL-gecodeerde tekst boven Base64.

SEO en toegankelijkheid

Data-URI’s verschijnen in de HTML-bron maar niet in aparte bestanden. alt-tekst werkt nog steeds normaal op <img> met data-URI’s — gebruik het. Rechtermuisklik → afbeelding opslaan werkt in de browser, maar de opgeslagen bestandsnaam is generiek. En Content Security Policy-regels kunnen expliciete toestemming nodig hebben voor data:-URI’s.

Data-URI’s zijn een precisie-tool. Gebruikt voor de juiste asset op de juiste plek schelen ze een request en versnellen ze een pagina. Ongericht gebruikt blazen ze je HTML op. De dertig seconden die het kost om te beslissen “is dit echt de juiste keuze?” betaalt zichzelf terug.

Wil je nu een afbeelding naar Base64 converteren, dan handelt onze Base64-encoder het af. Drop het bestand erin, kopieer de string, bouw de data-URI. Alles draait lokaal, dus zelfs bedrijfslogo’s of privé-assets blijven op je apparaat.