Base64 vs URL-encoding: wat is het verschil?

“Base64-encoding” en “URL-encoding” klinken alsof ze vergelijkbare dingen doen — beide converteren data naar een andere representatie met alleen veilige tekens. Maar ze lossen verschillende problemen op, produceren heel verschillende output en worden op verschillende plekken gebruikt. De twee verwarren is een betrouwbare manier om API’s te breken, links te verminken en uren te verliezen aan debuggen.

De twee encodings in één oogopslag

	Base64	URL-encoding (percent-encoding)
Doel	Binaire data als tekst representeren	Strings veilig maken voor URL’s
Alfabet	64 tekens (A-Z, a-z, 0-9, +, /)	Alle afdrukbare ASCII, gebruikt %XX voor onveilige tekens
Grootte-toename	Precies +33%	Variabel (meestal +0-200% afhankelijk van content)
Gebruikt in	E-mail, JSON, data-URI’s, JWT’s	URL’s, forminzendingen, query strings
Input	Bytes	Tekst (meestal een string met speciale tekens)

Wat URL-encoding echt doet

URL-encoding (formeel percent-encoding, gedefinieerd in RFC 3986) is het schema waarmee je willekeurige tekst in een URL kunt stoppen zonder hem te breken.

URL’s hebben structuur:

https://example.com/search?q=coffee&lang=en

Bepaalde tekens hebben speciale betekenis: ? scheidt het pad van de query string, & scheidt parameters, = scheidt key van value, / scheidt pad-segmenten, # start het fragment.

Wil je een van die tekens als data opnemen — bijv. een query voor “A & B” — dan moet je ze escapen. URL-encoding doet dit door elk speciaal teken te vervangen door % gevolgd door de twee-cijferige hexadecimale ASCII-code:

• Spatie → %20 (of soms + in query strings)
• & → %26
• = → %3D
• # → %23

Dus A & B wordt A%20%26%20B. Veilige tekens (letters, cijfers, -, _, ., ~) gaan ongewijzigd door.

Wat Base64 echt doet

Base64 is compleet anders. Het neemt bytes — niet per se tekst — en produceert tekst die alleen de 64 tekens in zijn alfabet gebruikt. Elke 3 bytes input worden 4 tekens output, altijd. Base64 maakt niet uit wat de input is; het behandelt alles als bytes.

De output is precies 33% langer dan de input, met =-padding tot het dichtstbijzijnde veelvoud van 4 tekens.

Base64 is de go-to wanneer je binaire data — een PNG-afbeelding, een zip-bestand, een versleutelde blob — door een alleen-tekst kanaal zoals e-mail of JSON moet krijgen. URL-encoding kan dat niet echt; het is ontworpen voor tekst-naar-tekst transformatie, niet voor willekeurige binaire data.

De overlap: wanneer je beide nodig hebt

Er is één specifiek scenario waarin beide encodings opduiken: binaire data in een URL plaatsen.

Stel je hebt een piepkleine afbeelding (20 bytes PNG) en je wilt die als parameter in een URL inbedden:

1. Base64-codeer de afbeelding → je krijgt een 28-karakter string
2. URL-codeer de Base64-string → de +, / en =-tekens worden %2B, %2F, %3D

Omdat deze combinatie zo gebruikelijk is, bestaat een variant genaamd Base64 URL-safe. Die gebruikt - en _ in plaats van + en / (die in URL’s zonder escapen veilig zijn) en laat meestal de =-padding weg:

• Standaard Base64: a+b/c=
• URL-safe Base64: a-b_c

JWT’s gebruiken URL-safe Base64, wat verklaart waarom je strings als eyJhbGciOiJIUzI1NiJ9 ziet zonder + of /.

Naast-elkaar-voorbeeld

Input: de tekst Hello, world! (13 bytes)

URL-encoding (escapet de komma, spatie en !):

Hello%2C%20world%21

Lengte: 19 tekens. Nog steeds leesbaar.

Base64-encoding (converteert de 13 bytes naar tekst):

SGVsbG8sIHdvcmxkIQ==

Lengte: 20 tekens. Niet leesbaar.

URL-safe Base64 (Base64 zonder tekens die escapen nodig hebben):

SGVsbG8sIHdvcmxkIQ

Lengte: 18 tekens. Gebruikt in JWT’s en compacte ID’s.

Wanneer URL-encoding gebruiken

Grijp naar URL-encoding wanneer je user input inbedt in een URL-pad of query string, wanneer je speciale tekens escapet in forminzendingen, of wanneer je REST API-URL’s bouwt met dynamische parameters.

Gebruik geen URL-encoding voor binaire data — het handelt willekeurige bytes niet goed af. Voor afbeeldingen of bestanden heb je eerst Base64 nodig.

Wanneer Base64 gebruiken

Base64 heb je nodig wanneer je binaire data overdraagt door een alleen-tekst kanaal (JSON, e-mail, XML), wanneer je kleine bestanden inbedt in HTML of CSS via data-URI’s, of wanneer je werkt met tokens en certificaten die als bytes komen maar als tekst moeten worden opgeslagen.

Gebruik geen Base64 wanneer de data al tekst is en je alleen speciale tekens voor een URL moet escapen — daarvoor is URL-encoding de juiste tool. En als grootte telt en je een binary-safe kanaal hebt, stuur dan gewoon de bytes direct.

Veelvoorkomende verwarring

“Ik heb een string Base64-gecodeerd om in een URL te zetten en het is nog kapot.” Base64-output bevat +, / en = — die allemaal speciale betekenis hebben in URL’s. Je moet de Base64-string ook URL-coderen, of direct de URL-safe Base64-variant gebruiken.

“Ik heb een bestand URL-gecodeerd maar het is corrupt.” URL-encoding behandelt input als tekst, wat betekent dat niet-ASCII bytes inconsistent worden afgehandeld. Voor binaire bestanden heb je eerst Base64 nodig.

“De API zegt dat ik het wachtwoord Base64 moet coderen voor Basic Auth.” HTTP Basic Authentication neemt username:password, Base64-codeert die string en zet het in de Authorization-header. Dit is niet omdat Base64 veilig is — het is omdat de header transmissie moet overleven door systemen die speciale tekens zouden kunnen verminken. De beveiliging komt van HTTPS, niet van Base64.

Een praktische workflow

Onze Base64-tool handelt encoderen en decoderen af — tekst of bestand erin, Base64 eruit, en omgekeerd. Alles draait lokaal, dus zelfs gevoelige tokens blijven op je apparaat.

Voor URL-encoding specifiek heeft elke taal een oneliner:

• JavaScript: encodeURIComponent(str) / decodeURIComponent(str)
• Python: urllib.parse.quote(str) / urllib.parse.unquote(str)
• PHP: urlencode($str) / urldecode($str)
• Ruby: CGI.escape(str) / CGI.unescape(str)

En voor gecombineerde scenario’s — binaire data in een URL — is het standaard-patroon: eerst Base64, daarna URL-encoden als nodig (of gebruik direct URL-safe Base64).

Zodra je de vuistregel verinnerlijkt — “URL-encoding voor tekst-naar-URL, Base64 voor bytes-naar-tekst” — verdwijnt de verwarring. Het zijn gewoon twee tools voor twee verschillende problemen.