Base64-codering uitgelegd: Wanneer en waarom je het gebruikt

Je hebt Base64 vast al eens gezien — die lange, vreemde strings zoals SGVsbG8gV29ybGQ=. Ze duiken op in e-mails, data-URI's, API-payloads en JWT's. Maar wat is Base64 eigenlijk, en wanneer moet je het gebruiken? Laten we het ontrafelen.

Wat Base64 doet (in gewone taal)

Base64 neemt willekeurige data — tekst, afbeeldingen, bestanden, wat dan ook — en converteert het naar een string met slechts 64 "veilige" ASCII-tekens: A-Z, a-z, 0-9, + en /. Het = aan het einde is padding.

Waarom? Omdat niet elk systeem ruwe binaire data aankan. E-mail is ontworpen voor tekst. JSON ondersteunt geen binair. URL-parameters kunnen geen willekeurige bytes bevatten. Base64 is de brug die binaire data door tekst-kanalen loodst.

Hoe het onder de motorkap werkt

Het algoritme is verrassend eenvoudig. Het neemt 3 bytes invoer (24 bits), splitst ze in 4 groepen van 6 bits elk, en mapt elke groep naar een van de 64 tekens. Hier is een snel voorbeeld:

Invoer: Hi (2 bytes: 72, 105)

Binair: 01001000 01101001 + opvulnullen

Gesplitst in 6-bit groepen: 010010 000110 100100

Gemapt naar Base64-alfabet: SGk=

De wiskunde betekent dat Base64-uitvoer altijd ongeveer 33% groter is dan de invoer. Dat is de afweging voor veilige tekstoverdracht. De RFC 4648-specificatie definieert het exacte algoritme als je de details wilt.

Wanneer je Base64 moet gebruiken

Kleine afbeeldingen insluiten in HTML/CSS: In plaats van de browser een apart bestand te laten ophalen, kun je een klein icoon inline plaatsen: . Dit bespaart een HTTP-verzoek. Ideaal voor iconen onder 2-3KB.

Binaire data versturen in JSON-API's: JSON kan geen ruwe bytes opslaan. Moet je een bestand uploaden via een JSON-API? Base64-codeer het:

E-mailbijlagen: Hier is Base64 letterlijk voor ontworpen. MIME-codering gebruikt Base64 om binaire bijlagen in tekstgebaseerde e-mailberichten in te sluiten.

JWT's en authenticatietokens: JSON Web Tokens gebruiken Base64URL-codering (een URL-veilige variant) voor hun header- en payload-secties.

Binaire data opslaan in tekstvelden: Databasetekstkolommen, omgevingsvariabelen, configuratiebestanden — Base64 laat je binaire data overal plaatsen waar tekst kan.

Wanneer je Base64 NIET moet gebruiken

• Grote bestanden. Die 33% toename doet echt pijn bij grote bestanden. Een afbeelding van 10MB wordt 13,3MB in Base64. Gebruik in plaats daarvan multipart form upload.
• Beveiliging. Base64 is geen encryptie. Het is triviaal omkeerbaar. Gebruik het nooit om wachtwoorden of gevoelige data te "verbergen". Iedereen kan cGFzc3dvcmQ= in seconden terugdecoderen naar password.
• Grote inline afbeeldingen. Voor afbeeldingen boven ~5KB presteert een apart bestand met goede HTTP-caching beter dan een Base64-data-URI.

De URL-veilige variant

Standaard Base64 gebruikt + en /, die een speciale betekenis hebben in URL's. De Base64URL-variant vervangt deze door - en _. Je ziet dit in JWT's en overal waar Base64-data in URL's verschijnt.

Snelle codevoorbeelden

Zo codeer en decodeer je Base64 in de meest voorkomende talen:

Let op dat JavaScript's browser btoa()-functie alleen werkt met ASCII-strings. Als je Unicode-tekst moet coderen, moet je een extra stap doen via TextEncoder — daar lopen veel ontwikkelaars tegenaan.

Veelgemaakte fouten met Base64

Hier zijn de valkuilen waar ik ontwikkelaars het vaakst in zie trappen:

1. Aannemen dat Base64 encryptie is. Ik kan dit niet genoeg benadrukken. Ik heb productiecodebases gezien die API-sleutels en wachtwoorden Base64-coderen, denkend dat ze "beschermd" zijn. Iedereen met een browserconsole kan ze direct decoderen. Als je data moet beschermen, gebruik echte encryptie (AES, RSA) of hashing (bcrypt, argon2).

2. Padding niet correct afhandelen. Sommige implementaties verwijderen de afsluitende =-tekens, wat kan leiden tot decoderingsfouten bij strikte parsers. Als je Base64 tussen systemen verstuurt, spreek af of padding wel of niet wordt meegenomen.

3. Standaard Base64 gebruiken in URL's. De + en / tekens in standaard Base64 zullen URL's breken. Gebruik altijd de URL-veilige variant (Base64URL) wanneer je gecodeerde data insluit in queryparameters of padsegmenten.

4. Grote bestanden Base64-coderen in JSON-payloads. Een 5MB-bestand wordt bijna 7MB na Base64-codering, en die hele string moet in het geheugen passen. Voor alles groter dan een paar KB, gebruik in plaats daarvan multipart/form-data.

Base64-tekenset snelreferentie

Praktijkvoorbeeld: Lettertypen insluiten in CSS

Een veelvoorkomend gebruik van Base64 waar je misschien niet aan denkt, is het direct insluiten van aangepaste lettertypen in CSS-bestanden. Dit vermijdt een extra HTTP-verzoek voor het lettertypebestand:

Deze techniek werkt goed voor kleine icoonlettertypen (onder 10-15KB). Voor grotere lettertypebestanden is het beter om ze apart aan te bieden zodat de browser ze onafhankelijk kan cachen.

Base64 vs andere coderingsschema's

Base64 is niet de enige manier om binaire data als tekst weer te geven. Er zijn verschillende alternatieven, en elk heeft zijn sterke punt. Laten we de belangrijkste vergelijken.

Hex-codering (Base16): De eenvoudigste aanpak — elke byte wordt twee hex-tekens (0-9, A-F). Dus Hi wordt 4869. Het is heel eenvoudig en menselijk leesbaar, maar de uitvoer is 100% groter dan de invoer (dubbele grootte). Hex zie je overal: kleurcodes (#FF5733), SHA-hashes, MAC-adressen en debug-uitvoer.

Base32: Gebruikt 32 tekens (A-Z en 2-7). De uitvoer is ongeveer 60% groter dan de invoer. Je hebt het waarschijnlijk al gezien zonder het te beseffen — die 6-cijferige codes van Google Authenticator en andere TOTP/2FA-apps gebruiken onder de motorkap Base32-gecodeerde geheimen. Het is ook hoofdletterongevoelig, wat het geweldig maakt voor situaties waarin gebruikers de gecodeerde data handmatig moeten invoeren.

ASCII85 / Base85: Gebruikt 85 afdrukbare ASCII-tekens en produceert uitvoer die slechts ongeveer 25% groter is dan de invoer. Dat is efficiënter dan Base64. Git gebruikt een variant van Base85 in zijn binaire patchformaat (packfiles), en Adobe PostScript- en PDF-bestanden gebruiken intern ASCII85-codering. Het nadeel? Het gebruikt tekens zoals {, } en aanhalingstekens die hoofdpijn kunnen veroorzaken in JSON, XML en URL's.

Hier is een vergelijking bij het coderen van dezelfde 100-byte invoer:

Waarom wint Base64 in de meeste gevallen? Het raakt de sweet spot: redelijke overhead, breed ondersteund in elke taal en platform, en het vermijdt de meeste speciale tekens die problemen veroorzaken in gangbare formaten. Base85 is compacter maar minder universeel ondersteund en moeilijker veilig te gebruiken in gestructureerde tekstformaten.

Base64 in authenticatiestromen

Een van de meest wijdverspreide (en meest verkeerd begrepen) toepassingen van Base64 is in HTTP Basic Authentication. Wanneer je een gebruikersnaam en wachtwoord via Basic Auth verstuurt, voegt de browser ze samen met een dubbele punt en Base64-codeert het resultaat.

Dit is wat er achter de schermen gebeurt wanneer je inlogt met gebruikersnaam admin en wachtwoord secret123:

De server ontvangt die header, Base64-decodeert het, splitst op de dubbele punt en controleert de inloggegevens. Simpel, toch? Maar hier is het cruciale punt: dit is NIET veilig zonder HTTPS. Die Base64-string is triviaal omkeerbaar — iedereen die het verzoek onderschept kan YWRtaW46c2VjcmV0MTIz decoderen en je wachtwoord in minder dan een seconde achterhalen. De RFC 7617-specificatie voor Basic Auth waarschuwt hier expliciet voor.

Base64 verschijnt ook in andere authenticatiecontexten. OAuth 2.0 access tokens en refresh tokens zijn vaak Base64-gecodeerd (hoewel dit een implementatiedetail is, geen vereiste). Veel API-sleutels van diensten zoals AWS, Stripe en Google Cloud zijn Base64-gecodeerde strings. Nogmaals, de codering is voor veilig transport — niet voor beveiliging. Verstuur ze altijd via HTTPS en bewaar ze veilig.

Data-URI's in detail

We noemden data-URI's eerder kort, maar ze verdienen een diepere blik. Een data-URI laat je bestandsinhoud direct insluiten in HTML, CSS of JavaScript — geen extern HTTP-verzoek nodig. De volledige syntax is:

Het mediatype is een standaard MIME-type, de ;base64-vlag vertelt de browser dat de data Base64-gecodeerd is (zonder deze wordt aangenomen dat de data URL-gecodeerde tekst is), en is de werkelijke inhoud.

Hier zijn voorbeelden voor verschillende mediatypen:

PNG-afbeelding (meest voorkomend):

Inline SVG (geen Base64 nodig!):

Merk op dat SVG's al tekst zijn, dus je kunt ze URL-coderen in plaats van Base64-coderen. Dit is eigenlijk kleiner omdat je de 33% overhead overslaat. Slimme ontwikkelaars gebruiken deze truc voor eenvoudige SVG-iconen.

PDF-document:

Audiobestand:

Nu over browserlimieten. Hoewel de data-URI-specificatie op MDN geen maximale grootte definieert, leggen browsers hun eigen limieten op. Chrome beperkt data-URI's tot ongeveer 2MB in navigatiecontexten (zoals iframes en pagina's op het hoogste niveau). Firefox is ruimhartiger. Voor CSS-achtergrondafbeeldingen en inline afbeeldingen is de praktische limiet het geduld van je gebruikers — een Base64-string van 500KB in je CSS-bestand is technisch geldig maar zal de laadtijden absoluut vernietigen.

Prestatie-impact: Wanneer Base64 pijn doet

Laten we het over echte cijfers hebben, want "33% overhead" klinkt abstract totdat je de impact in de praktijk ziet.

Bandbreedtekosten: Een afbeelding van 50KB wordt ~67KB na Base64-codering. Dat is 17KB extra per afbeelding. Vermenigvuldig dat over een pagina met 20 inline iconen en je verstuurt 340KB aan onnodige data. Ter referentie: dat is meer dan de hele HTML van de meeste webpagina's.

Geheugengebruik: Wanneer je een afbeelding Base64-codeert en insluit in HTML of CSS, moet de hele gecodeerde string in het geheugen worden gehouden als onderdeel van de DOM of stylesheet. De browser decodeert het vervolgens terug naar binair, dus kort houd je zowel de gecodeerde als de gedecodeerde versie vast. Voor een afbeelding van 1MB is dat ongeveer 2,33MB alleen voor de gecodeerde string, plus 1MB voor de gedecodeerde binaire data — meer dan 3x de oorspronkelijke bestandsgrootte.

Parsetijd: Base64-strings in HTML of CSS moeten worden geparsed als onderdeel van die documenten. Een grote data-URI maakt het hele CSS-bestand of HTML-document langzamer om te parsen. Volgens de beeldoptimalisatiegids van web.dev moeten inline afbeeldingen over het algemeen onder 2-4KB zijn om een netto prestatievoordeel te bieden.

Cache-inefficiëntie: Dit is degene die ontwikkelaars het meest over het hoofd zien. Wanneer je een afbeelding als apart bestand aanbiedt, cachet de browser het onafhankelijk — volgende paginaladingen slaan de download volledig over. Maar wanneer je diezelfde afbeelding Base64-gecodeerd in je CSS-bestand insluit, wordt het onderdeel van de CSS. Als je iets anders in de CSS wijzigt, downloadt de browser het hele bestand opnieuw, inclusief de Base64-afbeeldingsdata die niet zijn gewijzigd. Je verliest granulaire caching.

Hier is een ruwe benchmark ter perspectief:

De vuistregel: Base64-inline alles onder 2-4KB. Bied al het andere aan als apart bestand. Met HTTP/2 en HTTP/3 zijn de kosten van extra verzoeken minimaal, dus de drempel is door de jaren heen zelfs lager geworden.

Base64 in verschillende programmeertalen

We behandelden JavaScript en Python eerder. Zo ga je om met Base64 in andere populaire talen — elk slechts een paar regels:

Merk op dat elke taal Base64 in zijn standaardbibliotheek heeft — geen pakketten van derden nodig. Dat getuigt van hoe fundamenteel deze codering is. Let ook op dat Ruby strict_encode64 (geen regelovergangen) en encode64 (voegt regelovergangen in om de 60 tekens, overeenkomend met de originele MIME-standaard) heeft. De meeste moderne toepassingen willen de strikte versie.

De geschiedenis van Base64

Base64 verscheen niet uit het niets. Het verhaal is verbonden met de geschiedenis van e-mail, en het begrijpen ervan verklaart veel van de ontwerpbeslissingen.

In de vroege dagen van het internet was e-mail (SMTP) ontworpen om alleen 7-bit ASCII-tekst te verwerken — 128 tekens, en dat was het. Dit was prima voor Engelse tekst, maar compleet nutteloos voor het versturen van afbeeldingen, documenten of zelfs tekst in niet-Engelse talen. Je kon simpelweg geen binaire data via e-mail versturen.

De eerste formele specificatie van Base64 verscheen in RFC 1421 in 1993, als onderdeel van de Privacy Enhanced Mail (PEM) standaard. Het idee was eenvoudig: binaire data omzetten naar een subset van ASCII die elk tekstgebaseerd transportsysteem zou overleven zonder corruptie.

Toen kwam RFC 2045 in 1996, die MIME (Multipurpose Internet Mail Extensions) definieerde. MIME standaardiseerde hoe e-mailbijlagen werken, en Base64 was de primaire codering voor binaire inhoud. Daarom zie je vandaag nog steeds Content-Transfer-Encoding: base64 headers in ruwe e-mailberichten.

De codering werd opnieuw verfijnd in RFC 4648 (2006), die de definitieve referentie werd. Deze RFC introduceerde ook de URL-veilige variant (Base64URL) en verduidelijkte randgevallen rond padding. De MDN Base64-woordenlijstpagina is een goed startpunt als je de specificatie wilt verkennen zonder ruwe RFC's te lezen.

Wat fascinerend is, is dat Base64 werd geboren uit een beperking — 7-bit e-mail — die niet meer bestaat. Modern SMTP ondersteunt 8-bit en binaire overdracht. Toch heeft Base64 zijn oorspronkelijke doel ruimschoots overleefd, en vindt het nieuw leven in web-API's, JWT's, data-URI's en talloze andere contexten. Het is een van die technologieën die een probleem zo goed oplosten dat mensen steeds nieuwe problemen vinden om het op te lossen.

Probeer het zelf

Wil je Base64 in actie zien? Plak willekeurige tekst of een bestand in onze Base64 Encoder om de gecodeerde uitvoer direct te zien. Moet je iets decoderen? De Base64 Decoder regelt dat. En als je werkt met Base64-gecodeerde afbeeldingen, laat onze Base64 to Image-tool je ze direct in de browser bekijken.