Waarom andere Base64-tools stukgaan op emoji
btoa(), de eigen Base64-functie van de browser, kent alleen Latin-1: elk teken moet één byte van 0 tot 255 zijn. Krijgt hij een emoji, of vrijwel het hele Chinees, Japans of Koreaans, dan gooit hij een fout. Krijgt hij een letter met een accent, dan doet hij iets ergers dan een fout gooien: café wordt Y2Fm6Q==, vier Latin-1-bytes, geen foutmelding, en verkeerd voor alles verderop dat UTF-8 leest. Deze tool haalt de tekst eerst door TextEncoder, zodat er alleen UTF-8-bytes bij btoa() aankomen.
Base64 is geen encryptie
Iedereen kan Base64 zonder sleutel terugdraaien naar de originele bytes, want voor het coderen was er ook geen sleutel nodig. Er een wachtwoord mee "verbergen" in een configbestand of een API-request is hooguit obfuscatie. Het doel is binaire data door formaten sturen die alleen tekst begrijpen: een afbeelding in CSS, de header en payload van een JWT, een MIME-bijlage.
Veelvoorkomende problemen
- "Ongeldig teken" is meestal het verkeerde alfabet: een plus of slash terwijl URL-veilig aanstaat, een streepje of underscore terwijl het uitstaat. De twee alfabetten worden apart gehouden.
- Onvolledige Base64: het komt in groepen van 4, en een plakactie die één teken tekortkomt is niet met padding te herstellen. Dat wordt gemeld, niet geraden.
- "Geen geldige UTF-8-tekst" betekent dat de bytes wel decodeerden, maar een bestand bevatten en geen tekst. Download ze dan in plaats van ze als tekens te lezen.
- Regeleinden in een geplakt token, normaal zodra Base64 op 76 kolommen is afgebroken voor MIME of een PEM-bestand, worden genegeerd in plaats van als ongeldig gezien.
Veelgestelde vragen
Waarom is het resultaat een derde groter dan de invoer?
Omdat de codering 3 bytes in 4 tekens propt. Dat kost elke keer 33,3%, per definitie, en geen enkele implementatie ontkomt eraan. Het is de prijs van binaire data door iets sturen dat alleen tekst accepteert.
Verandert coderen het bestand zelf?
Geen byte. Base64 is een omkeerbare tekstweergave van precies de invoer, dus decoderen levert een bestand op dat identiek is aan het origineel, metadata inbegrepen. Het is een transportformaat, geen bewerking.
Waarom mislukt mijn decode op een paddingfout?
De lengte van een Base64-tekst modulo 4 kan 0, 2 of 3 zijn, nooit 1: één los teken draagt 6 bits, en geen enkele reeks bytes eindigt precies daarop. Een lengte van één boven een veelvoud van 4 betekent dat er onderweg tekens verloren zijn gegaan, meestal aan een regelafbreking of een afgekapte kopie.
Wordt mijn invoer geüpload?
Nee. Tekst en bestanden worden allebei in dit tabblad gecodeerd, en er gaat niets naar buiten. Goed om te weten, want wat mensen hier decoderen zijn heel vaak tokens en inloggegevens.
Wat is het verschil tussen standaard en URL-veilige Base64?
Hetzelfde alfabet en dezelfde bitverdeling, met + vervangen door -, / door _, en de = padding weggelaten (RFC 4648 §5). +, / en = betekenen in een URL alle drie al iets, en daarom gebruiken de header en payload van een JWT deze variant.