Over deze tool
Deze gratis Base64-encoder / -decoder zet tekst om naar en van Base64. Hij is UTF-8-veilig, dus emoji, letters met accenten, Chinees, Japans, Koreaans, Arabisch en Cyrillisch overleven de heen- en terugweg ongeschonden — wat van verrassend veel Base64-tools niet gezegd kan worden.
Alles draait in uw browser. Niets van wat u plakt wordt geüpload, gelogd of door iemand gezien. Dat telt hier zwaarder dan bij de meeste tools: mensen plakken de hele dag API-sleutels, tokens en stukjes configuratie in Base64-omzetters.
Wat Base64 eigenlijk is
Base64 is geen versleuteling. En ook geen compressie. Het is een manier om *willekeurige* gegevens te herschrijven met slechts 64 tekens die vrijwel overal veilig verstuurd kunnen worden: A–Z, a–z, 0–9, + en /, met = als opvulling aan het eind.
De reden dat het bestaat is historisch en nog steeds actueel. Veel systemen zijn gebouwd om tekst te vervoeren, niet willekeurige bytes — e-mailteksten, JSON-strings, XML-attributen, HTTP-headers, URL's, omgevingsvariabelen. Geef zo'n systeem een ruwe byte als 0x00 of 0x1B en iets onderweg zal die verminken, weghalen of het bericht weigeren. Base64 omzeilt het hele probleem door die bytes in gewone letters en cijfers te veranderen waar niets bezwaar tegen maakt.
Het mechanisme is eenvoudig: Base64 neemt uw gegevens per 3 bytes (24 bits) en schrijft ze als 4 tekens (elk 6 bits). Die verhouding is de reden dat Base64-uitvoer altijd ongeveer 33% groter is dan de invoer. Wanneer de gegevens niet netjes door 3 deelbaar zijn, wordt de laatste groep aangevuld met één of twee =.
Base64 is geen geheim
Dit moet onomwonden gezegd worden, want het veroorzaakt echte beveiligingsincidenten.
Iedereen kan Base64 decoderen. Er is geen sleutel, geen wachtwoord, geen geheim. Deze pagina decodeert het in een oogwenk, en elke ontwikkelaar, elke logscanner en elke aanvaller die het vindt net zo goed. cGFzc3dvcmQxMjM= is geen verborgen wachtwoord — het is het woord password123 in een heel dunne vermomming.
Dus: Base64 is prima voor transport. Het is nooit een manier geweest om iets te beschermen. Moet iets onleesbaar blijven, dan hebt u echte versleuteling nodig. Dat een waarde er door elkaar gehusseld *uitziet*, betekent niet dat hij beschermd *is*.
Dit werkt ook de andere kant op, en dat is nuttig: vindt u in een logbestand, een configuratie of een URL een lange reeks letters en cijfers die op = eindigt, dan is dat vrijwel zeker Base64 — en kunt u het gewoon lezen.
Waar u het tegenkomt
- Data-URL's — data:image/png;base64,iVBORw0KGgo… zet een afbeelding rechtstreeks in HTML of CSS, zonder apart bestand
- HTTP Basic-authenticatie — de Authorization-header is letterlijk gebruiker:wachtwoord in Base64, en precies daarom is Basic Auth zonder HTTPS onveilig
- JSON Web Tokens — een JWT bestaat uit drie Base64url-blokken met punten ertussen; de eerste twee zijn gewoon leesbare JSON
- E-mailbijlagen — MIME vervoert al decennia binaire bestanden via Base64 door systemen die alleen tekst aankunnen
- Configuratie- en secrets-bestanden — Kubernetes-secrets, .env-bestanden en CI-variabelen slaan waarden vaak Base64-gecodeerd op, opnieuw voor transport en niet voor veiligheid
- API's — elk veld dat binaire gegevens in een JSON-string moet dragen
UTF-8, en waarom sommige tools het fout doen
Base64 codeert bytes, geen tekens. Voordat er iets gecodeerd kan worden moet tekst dus in bytes worden omgezet — en juist daar breken tools stilletjes.
De klassieke fout is een byte-per-teken-omzetting op tekst die iets buiten pure ASCII bevat. Plak café, 日本語 of een emoji in een zo geschreven tool en u krijgt een foutmelding of, erger, stilzwijgend beschadigde uitvoer die als onzin terugkomt.
Deze tool zet uw tekst eerst om naar UTF-8, de codering die het web werkelijk gebruikt. é, →, 🎉 en 한국어 worden precies zo gecodeerd en gedecodeerd als u ze typte.
Standaard-Base64 en Base64url
Er zijn twee smaken, en ze verwarren is een veelvoorkomende oorzaak van «dit is geen geldige Base64»-fouten.
Standaard-Base64 gebruikt + en / als laatste twee tekens. Dat is wat deze tool maakt, en wat vrijwel alles verwacht.
Base64url vervangt die door - en _ en laat de =-opvulling meestal weg. Het bestaat omdat + en / binnen een URL en een bestandspad hun eigen betekenis hebben en dus ontsnapt zouden moeten worden. JWT's gebruiken Base64url, net als veel API's die gecodeerde waarden in een pad of query string zetten.
Mislukt het decoderen bij een reeks vol - en _, dan is dat de reden. Ze terugveranderen in + en / lost het meestal op.
Zo gebruikt u het
- Plak uw tekst (of Base64) in het veld
- Codeer of Decodeer met de knoppen
- Wissel om het resultaat in de invoer te zetten en de andere kant op te gaan
- Kopieer het resultaat
Goed om te weten
- Base64-uitvoer is ~33% groter dan de invoer. Een afbeelding van 3 MB wordt als data-URL ongeveer 4 MB — het onthouden waard voordat u grote bestanden insluit.
- Witruimte is meestal onschadelijk. Veel systemen breken Base64 af op 76 tekens per regel; decoders negeren die regeleinden normaal gesproken.
- De = staat alleen aan het eind, nooit in het midden. Eén of twee, nooit drie.
- De lengte is altijd een veelvoud van 4 zodra de opvulling meetelt. Is die van u dat niet, dan is er iets afgekapt.
- Willekeurige binaire data terug naar tekst decoderen ziet eruit als onzin. Decodeert u een PNG, dan krijgt u bytes, geen woorden — dat klopt, het is geen fout.
Veelgestelde vragen
Is Base64 versleuteling?
Nee, en dat is het belangrijkste om te weten. Base64 heeft geen sleutel en geen geheim. Iedereen die de reeks ziet kan hem in één stap decoderen, deze pagina inbegrepen. Het is een codering voor veilig transport, geen bescherming. Gebruik het nooit om een wachtwoord, een token of iets anders van belang te verbergen.
Waarom eindigt mijn Base64 op één of twee isgelijktekens?
Dat is opvulling. Base64 werkt met groepen van 3 bytes die 4 tekens worden. Wanneer uw gegevens niet netjes door 3 deelbaar zijn, is de laatste groep te kort en wordt hij met = aangevuld zodat de totale lengte een veelvoud van 4 blijft. Eén overgebleven byte geeft ==, twee bytes geven =, en een exact veelvoud geeft helemaal geen opvulling.
Waarom is mijn Base64-reeks langer dan het origineel?
Omdat elke 3 bytes 4 tekens worden, is de uitvoer altijd ongeveer 33% groter dan de invoer, plus maximaal twee opvultekens. Dat is onvermijdelijk en het is de prijs om willekeurige gegevens veilig in een tekstveld te kunnen zetten. Als omvang uitmaakt, comprimeer de gegevens dan vóór het coderen, niet erna.
Kan ik een afbeelding of een PDF in Base64 coderen?
Ja, en dat is een gangbaar gebruik — zo sluiten data-URL's afbeeldingen in HTML en CSS in. Deze tool werkt op tekst die u plakt, dus hij past bij tokens, JSON, configuratiewaarden en bestaande Base64-reeksen. Denk aan de toename van 33% voordat u iets groots insluit.
Waarom mislukt mijn decodering met «geen geldige Base64»?
De gebruikelijke oorzaken zijn een afgekapte reeks, losse tekens die zijn meegeplakt, of Base64url. Base64url gebruikt - en _ waar standaard-Base64 + en / gebruikt, en de opvulling is er vaak af gehaald — een JWT-blok dat u er rechtstreeks in plakt, decodeert dus mogelijk niet. Vervang - door + en _ door / en probeer het opnieuw.
Wordt mijn tekst naar een server gestuurd?
Nee. De hele omzetting gebeurt in uw browser met de ingebouwde functies. Er wordt niets geüpload en niets opgeslagen, en daarom blijft de tool werken met de verbinding uit. Gezien hoe vaak mensen inloggegevens in Base64-tools plakken, is dat precies het punt.
Gerelateerde tools
- URL-encoder / -decoder — de andere codering die u voortdurend tegenkomt in URL's en query strings
- JWT-decoder — leest de Base64url-blokken van een token voor u, zonder handmatig omwisselen
- Hash-generator — MD5, SHA-1 en SHA-256 die, anders dan Base64, maar één kant op werken
- Afbeelding naar Base64 — een echt afbeeldingsbestand omzetten in een data-URL
