Base64-encoder en -decoder

Inhoud	Bytes	Base64-tekens	Padding	Voorbeeld
Een ASCII-teken («A»)	1	4	« == »	QQ==
Twee tekens («AB»)	2	4	« = »	QUI=
Drie tekens («ABC»)	3	4	geen	QUJD
« Hello » (UTF-8)	5	8	« = »	SGVsbG8=
« Bonjour le monde ! » (UTF-8)	18	24	geen	Qm9uam91ciBsZSBtb25kZSAh
« é » (UTF-8)	2	4	geen	w6k=
« 日 » (UTF-8)	3	4	geen	5piv
Nulbyte (0x00)	1	4	« == »	AA==

Wat betekenen «encoder» en «decoder» bij Base64?

Base64 coderen («encode base64») zet bytes om — meestal de bytes van een in UTF-8 gecodeerde tekst — naar een string van 64 toegestane tekens: de 26 hoofdletters, de 26 kleine letters, de 10 cijfers en + en /. Base64 decoderen («decode base64») doet precies het omgekeerde: de string wordt in blokken van 4 tekens gelezen, elk teken staat voor 6 bits en 24 bits leveren 3 bytes op. Dat heen-en-weer is wat de meeste mensen zoeken wanneer ze «encode and decode base64» intoetsen.

Base64 is geen compressie en geen versleuteling: de tekst wordt ongeveer een derde langer en iedereen kan hem in een seconde lezen. Het nut zit in het transport van bytes over kanalen die alleen veilige ASCII-tekens accepteren — URL's, HTTP-headers, configuratiebestanden, JSON, inline SVG, e-mails, tekstdatabases.

Hoe codeer je tekst in Base64

Stap 1: de tekst wordt eerst omgezet in bytes volgens de gekozen tekencoding — standaard UTF-8, maar Latin-1, Windows-1252, ASCII of UTF-16 blijven nuttig voor oudere systemen. Stap 2: de bytes worden drie voor drie gelezen, samen 24 bits. Stap 3: deze 24 bits worden in vier blokken van 6 bits gesneden en elk blok wordt vervangen door het bijbehorende positieteken in het alfabet. Stap 4: is de laatste groep onvolledig, dan wordt die aangevuld met nullen en eindigt de string met één of twee = (de padding).

Stap voor stap: « AB » is 65 en 66 in decimaal, oftewel 01000001 01000010. In drie bytes met aanvulling: 01000001 01000010 00000000. De vier blokken van 6 bits zijn 010000 010100 001000 000000 → posities 16, 20, 8, 0 → QUI=. Typ gewoon «AB» in de encoder: het resultaat verschijnt nog voordat je de toets loslaat.

Hoe decodeer je een Base64-string naar tekst

De decoding leest de string in groepen van 4 tekens nadat regeleinden en eventuele spaties zijn verwijderd. Elk teken wordt vervangen door zijn 6-bitwaarde, de vier waarden worden aan 24 bits gekoppeld en die 24 bits worden in 3 bytes gesneden. De = aan het einde geven aan hoeveel echt bruikbare bytes de laatste groep bevat: een = betekent 2 bytes, twee = betekenen 1 byte.

Bevat de string - of _, dan gaat het om de URL-safe-variant: de tool zet ze automatisch om naar + en / vóór het decoderen. Ontbreekt de padding, dan herstelt de knop «Padding corrigeren» die. Bij een teken buiten het alfabet, een verkeerd geplaatste tab of een lengte die geen veelvoud van 4 is, verschijnt de fout met de exacte reden in plaats van een simpel «ongeldig».

URL-safe-variant (RFC 4648 §5)

Standaard Base64 gebruikt + en /, twee tekens die problemen geven in een URL: het + wordt door de meeste servers als spatie gelezen en het / kan worden verward met een padafscheiding. De URL-safe-variant vervangt ze door - en _, die geen escaping vragen. Het is verplicht bij JWT (de drie segmenten van een token worden zonder padding gecodeerd), bij cookies, bij identifiers en URL-parameters.

Padding «=»: waarvoor is dat goed?

Base64 werkt in groepen van 4 tekens, maar de omvang van een bestand is bijna nooit een veelvoud van 3 bytes. De padding herstelt de verwachte lengte: blijft er 1 byte over, dan ontstaat ==, blijven er 2 bytes over, dan ontstaat =. Sommige systemen verwijderen die (bepaalde API's, Base64URL), andere eisen die (PHP, oudere decoders). De optie «Zonder padding» van de encoder en de knop «Padding corrigeren» van de decoder dekken beide gevallen af.

Tekencodering: UTF-8, Latin-1, UTF-16

Base64 kent geen tekens, alleen bytes. De cruciale vraag is dus: waarmee codeer je de tekst vóór het Base64? In UTF-8 is «é» 2 bytes en «日» 3; in Latin-1 past «é» in 1 byte maar wordt «日» onmogelijk. Decodeer je een in Latin-1 gecodeerde string als UTF-8, dan krijg je vreemde tekens («mojibake»). Is het resultaat van een online tool onbegrijpelijk, dan verschilt bijna altijd de oorspronkelijke codering — vandaar de zes opties hier.

Bestand, data URI en afbeeldingen in Base64

Een data URI heeft de vorm data:<MIME-type>;base64,<gegevens>. Hiermee zet je een afbeelding direct in CSS, HTML of JSON: background-image:url(data:image/png;base64,iVBOR…). Om te decoderen plak je de hele string in het tabblad «Bestand ⇄ Base64»: het MIME-type wordt uitgelezen, er wordt een naam voorgesteld en daarna wordt het bestand opnieuw opgebouwd en gedownload. Let op de omvang: Base64 voegt ongeveer 33% toe en een data URI wordt nooit apart gecached.

Base64, URL-encoding en waarom je ze niet moet verwarren

De percent-encoding (%20, %C3%A9) vervangt elke niet-toegestane byte door een percentage: het is twee tot drie keer langer dan Base64 maar blijft visueel dicht bij de oorspronkelijke tekst. Base64 produceert een compacte, gelijkmatige string — perfect voor blobs, maar onleesbaar. Het tabblad «URL & data URI» zet beide conversies naast elkaar om de klassieke fout te vermijden: een URL in Base64 coderen in plaats van escapen — of omgekeerd.

Base64 in dagelijkse formaten

Base64 is overal: de drie segmenten van een JWT, het attribuut src van een inline SVG-afbeelding, het veld cert in een PDF, de attachments MIME van e-mails (RFC 2045), de Authorization: Basic van API's (gebruiker:wachtwoord), de bestanden .pem en SSH-sleutels, de inhoud van .docx en .xlsx (ZIP), de avatars in clientopslag en de data- attributen van geautomatiseerde tests. Snel kunnen coderen en decoderen voorkomt dat je voor één string een terminal opent.

Wat Base64 niet is

Base64 versleutelt niets: een gecodeerde string is met één regel code te ontcijferen. Gebruik het nooit als bescherming voor wachtwoorden, API-sleutels of persoonlijke gegevens. Het is ook geen compressie: reken altijd op 33% meer volume. En Base64 is boven enkele megabytes niet geschikt voor al dicht gecomprimeerde binairbestanden (PNG, ZIP), waar het geheugengebruik nadelig wordt.

Prestaties en beste praktijken

In de browser TextEncoder en TextDecoder verwerken meerdere megabytes per seconde; het Base64-algoritme zelf is lineair, zonder recursie en zonder allocatie per teken. Bestanden groter dan 5 MB kunnen de interface vertragen: voor grotere partijen is verwerking in een Web Worker of aan serverkant beter. Leg altijd de oorspronkelijke codering vast naast de string en test de round-trip (coderen en decoderen) voordat je een resultaat in een database opslaat.

Aanbevolen voor

Back-end- en front-endontwikkelaars (tokens, data URI, HTTP-headers), integrators en technische redacteuren (inline SVG, achtergrondafbeeldingen), systeembeheerders en DevOps (certificaten, sleutels, dumps), testers en pentesters (Authorization Basic, parameterfuzzing), studenten (bytes, ASCII en UTF-8 begrijpen) en iedereen die een Base64-encoder en -decoder online zoekt — snel, compleet en vertrouwelijk.

Base64-encoder en -decoder 100% lokaal: je gegevens verlaten nooit je computer

Anders dan bij klassieke online Base64-tools wordt niets verstuurd: coderen, decoderen en bestanden omzetten gebeuren volledig in je browser. Zo kun je zonder risico een wachtwoord, token, certificaat of intern codefragment coderen — zelfs in vliegmodus of op een openbaar netwerk. Geschiedenis en laatste invoer worden lokaal (localStorage) bewaard en blijven op je apparaat.

De licentie Premium Volade voegt een optionele, versleutelde cloudsynchronisatie toe die los van de tool draait — de rest blijft gratis en onbeperkt, zonder registratie.