Base64 kost altijd precies een derde

De codering propt 3 bytes in 4 tekens, dus de payload is 4/3 van het origineel plus opvulling: 33,3% straf, elke keer, nog voordat het voorvoegsel data:image/png;base64, meegeteld is. Dat is geen implementatiedetail waar je omheen kunt optimaliseren. Het is het rekenwerk van het formaat, en het is het getal dat elke pagina over "je afbeelding naar Base64 omzetten" noemt en daarna nooit tot zijn conclusie doorvoert.

Gzip redt het ook niet, en juist daar gaat het meeste advies mis. Tekst comprimeert goed; Base64 van al gecomprimeerde beelddata comprimeert nauwelijks, want de bronbytes lijken op willekeur. Reken op een paar procent, niet op de zeventig die je op HTML haalt. Wie een kale Base64-string tegen een gzipte binary legt laat inlinen er veel beter uitzien dan het is.

Wanneer inlinen goed is, en wanneer het een fout is

Onder ongeveer 2 kB: inline het. Een klein icoon, een opsommingsteken, een verloop van 1px: het uitgespaarde extra verzoek weegt op tegen de extra bytes, ook over HTTP/2, en zo klein is een eigen cache-plek niet waard. Een vervaagde plaatshouder van lage kwaliteit die met de HTML mee moet komen is het duidelijkste geval dat er is.

Voorbij ongeveer 10 kB: niet doen. De opgeblazen bytes worden opnieuw verstuurd op elke pagina die ze insluit, ze zijn niet apart van het document of de stylesheet die ze draagt te bewaren, en ze houden dat bestand tegen terwijl de browser eroverheen leest. Een foto van 200 kB als data URL in je CSS maakt de stylesheet 270 kB en blokkerend voor het tekenen, en dat is op elke maatstaf slechter dan één extra verzoek.

Daartussen hangt het af van waar het heen gaat, en daarom zegt deze pagina "meet het" in plaats van voor je te kiezen.

Veelvoorkomende problemen

De data URL werkt niet in CSS. Zet er aanhalingstekens omheen: url("data:…"). Een data URL zonder aanhalingstekens met een komma of een haakje erin beëindigt de url() te vroeg, en SVG-data-URL's zitten vol met allebei.
Een SVG-data URL is enorm. Zet een SVG niet in Base64. Het is tekst, dus percent-encoding is kleiner dan Base64 en blijft leesbaar en te gzippen. Base64 is voor binaire data.
De browser blokkeerde het. Navigatie op het hoogste niveau naar een data: URL wordt sinds 2017 in elke browser geblokkeerd, en een Content Security Policy zonder data: in img-src blokkeert het in een pagina. Geen van beide is een probleem met de string.
Regeleinden middenin. Sommige tools breken Base64 af op 76 tekens, wat klopt voor MIME e-mail en fout is binnen een data URL. Haal de regeleinden eruit.

Veelgestelde vragen

Wordt mijn afbeelding geüpload?

Nee. Het bestand wordt gelezen door de eigen FileReader van de browser en verlaat het tabblad nooit. Het decoderen gebruikt fetch op de data URL zelf, en dat is het ene geval waarin fetch helemaal geen verzoek doet: een data: URL wordt opgelost uit de string die al in het geheugen staat.

Waarin verschilt dit van de Base64-tool voor developers?

Andere vraag, dezelfde codering. Die pagina gaat over tekst en willekeurige bestanden, met URL-veilige alfabetten en correcte UTF-8. Deze gaat over de vraag of je een afbeelding moet inlinen, dus hij toont hoeveel groter het wordt, het oordeel en de HTML- en CSS-vormen om te plakken.

Waarom zit hier een groottelimiet op?

8 MB, en dat gaat over tekenen en niet over coderen. Een data URL voor een bestand van 8 MB is meer dan 10 miljoen tekens, en zoveel tekst in een codeblok uitlijnen is wat het tabblad zou bevriezen, niet de codering zelf.

Verandert coderen de afbeelding?

Geen byte. Base64 is een omkeerbare tekstweergave van precies het bestand, metadata en al. Controleer dat voordat je er een in een openbare repository plakt: de EXIF, GPS-coördinaten inbegrepen, zit er nog in. De compressor haalt metadata weg omdat hij de pixels hercodeert; deze tool niet, want die raakt ze niet aan.