Base64-codering en -decodering

Inleiding

De Base64 Encoder & Decoder is een gratis online tool voor het converteren van tekst naar Base64 en het decoderen van Base64 terug naar tekst. Beide bewerkingen gebeuren in real-time tijdens het typen, zonder paginavernieuwing of verzendknop. De tool draait volledig in uw browser — niets wordt naar een server gestuurd.

Twee onafhankelijke secties bevinden zich op dezelfde pagina: één voor coderen, één voor decoderen. Elk heeft zijn eigen tekstveld, uploadzone en actieknoppen, zodat u in beide richtingen kunt werken zonder van modus te wisselen.

Wat is Base64?

Base64 is een manier om binaire gegevens weer te geven met alleen afdrukbare ASCII-tekens. Het is geen versleutelings- of compressieschema — het doel is om binaire gegevens veilig te transporteren over systemen die zijn ontworpen voor tekst.

Hoe de codering werkt

Het Base64-alfabet gebruikt 64 tekens:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

Het coderingsproces verdeelt de invoer in groepen van 3 bytes (24 bits) en splitst vervolgens elke groep in vier 6-bit-waarden. Elke 6-bit-waarde (0–63) wordt toegewezen aan een teken in het alfabet.

Invoer:      F   o   o
Binair:      01000110 01101111 01101111
6-bit:       010001 100110 111101 101111
Decimaal:    17     38     61     47
Base64:      R     b    9     v

"Foo" wordt gecodeerd als Rm9v.

Waarom 64?

64 is gekozen omdat het de grootste macht van twee is die alleen tekens gebruikt die beschikbaar zijn in bijna alle tekensets (letters, cijfers en twee leestekens). Dit maakt Base64 betrouwbaar over e-mailsystemen, JSON-payloads, URL's en andere tekstgebaseerde kanalen die niet-ASCII-bytes kunnen verminken of afwijzen.

Elk Base64-teken draagt 6 bits informatie, vergeleken met 8 bits per byte. Deze 6:8-verhouding verklaart waarom de gecodeerde uitvoer ongeveer 33 % groter is dan de oorspronkelijke invoer — een onderwerp dat later in detail wordt behandeld.

Wanneer de invoer geen veelvoud van 3 bytes is

Als de laatste groep minder dan 3 bytes heeft, wordt padding toegevoegd. De encoder voegt =-tekens toe om de uitvoerlengte een veelvoud van 4 te maken:

• 1 byte over → 2 Base64-tekens + ==
• 2 bytes over → 3 Base64-tekens + =
• 3 bytes compleet → 4 Base64-tekens, geen padding

Bijvoorbeeld, "Fo" (2 bytes) wordt gecodeerd als Rm8=.

Een opmerking over wat Base64 niet is

Base64 wordt vaak verward met versleuteling omdat de uitvoer op willekeurige tekens lijkt. Een snelle decodering onthult de originele tekst zonder sleutel. Als u gegevens moet beschermen, gebruik dan een geschikt versleutelingsalgoritme (AES, ChaCha20, enz.) en codeer vervolgens de versleutelde bytes met Base64 voor transport. Base64 alleen biedt geen vertrouwelijkheid.

Veelvoorkomende toepassingen van Base64

Base64 komt op veel alledaagse plaatsen op het web voor, vaak zonder dat gebruikers het merken.

Data URI's

Moderne browsers staan u toe afbeeldingen, lettertypen en andere media rechtstreeks in HTML of CSS in te bedden met data: URI's:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA...">

De Base64-gecodeerde afbeeldingsgegevens leven in het HTML-bestand zelf — geen apart HTTP-verzoek nodig. Dit is gebruikelijk voor kleine pictogrammen, sprites en weblettertypen, waar de extra HTTP-roundtrip meer zou kosten dan de inline-bytes.

Base64 Data URI's zijn echter niet altijd de beste keuze voor grotere assets. De 33 % groottes overhead betekent dat een pictogram van 100 KB 133 KB inline-tekst wordt, en de browser kan het niet apart van de HTML-pagina cachen. De meeste sites gebruiken Data URI's alleen voor assets onder een paar kilobyte.

JWT- en API-tokens

JSON Web Tokens gebruiken Base64url (de URL-veilige variant) om de header-, payload- en handtekeningsegmenten van een token te coderen. Als u ooit een JWT zoals deze heeft geïnspecteerd:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U

elk door punten gescheiden segment is Base64url-gecodeerde JSON. U kunt elk segment in het decodeergedeelte van deze tool plakken om de inhoud te inspecteren.

E-mailbijlagen (MIME)

E-mail was oorspronkelijk ontworpen voor 7-bit ASCII. Om binaire bijlagen (afbeeldingen, PDF's, spreadsheets) te verzenden, codeert de MIME-standaard ze als Base64. Uw e-mailclient decodeert ze automatisch wanneer u het bericht opent.

Een detail dat soms verwarring veroorzaakt: MIME Base64 breekt conventioneel regels na 76 tekens. Als u Base64-gegevens uit een e-mailbron haalt, kunnen deze ingebedde regeleinden bevatten. De decoder van deze tool verwerkt regeleinden automatisch — u kunt meerregelig MIME Base64 plakken zonder eerst de regeleinden te verwijderen.

PEM-certificaten en sleutels

SSL/TLS-certificaten en privésleutels worden gedistribueerd in PEM-formaat, dat Base64-gecodeerde DER-gegevens verpakt tussen header- en footerregels:

-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
...
-----END CERTIFICATE-----

PEM is in wezen Base64 met een gelabelde verpakking. U kunt de Base64-body van een PEM-bestand decoderen om de ruwe DER-inhoud te inspecteren, hoewel het resultaat binair zal zijn, geen leesbare tekst.

HTTP-basisauthenticatie

De HTTP Basic-auth-header codeert gebruikersnaam:wachtwoord als Base64:

Authorization: Basic YWRtaW46c2VjcmV0

De tekenreeks YWRtaW46c2VjcmV0 is de Base64-codering van admin:secret. Base64 is hier een serialisatiemechanisme, geen beveiliging — de inloggegevens zijn triviaal te decoderen door iedereen die de header ziet.

Wat is een .b64-bestand?

Een .b64-bestand is een platte tekstbestand waarvan de volledige inhoud een Base64-tekenreeks is. De extensie .b64 is een naamgevingsconventie die aangeeft "dit bestand bevat Base64-gegevens" — in tegenstelling tot willekeurige tekst, broncode of een binair formaat.

U kunt .b64-bestanden tegenkomen wanneer:

• U gecodeerde uitvoer exporteert van tools zoals deze
• U cryptografische sleutels of certificaten opslaat in een draagbaar tekstformaat
• U Base64-gegevens uitwisselt tussen systemen die bestandsgebaseerde workflows gebruiken

Omdat .b64-bestanden platte tekst zijn, kunt u ze openen in elke teksteditor, de inhoud inspecteren of de tekenreeks in een decoder kopiëren. Deze tool accepteert .b64-bestanden in zowel het Codeer- als Decodeer-gedeelte via slepen of de bestandsselector.

Hoe het werkt

De tool gebruikt de ingebouwde Base64-functies van de browser met een extra laag voor UTF-8-veiligheid.

Kernconversie

JavaScript biedt twee native functies voor Base64:

• btoa(invoer) — converteert een tekenreeks naar Base64 (binair naar ASCII)
• atob(invoer) — converteert Base64 terug naar een tekenreeks (ASCII naar binair)

Deze functies werken alleen met Latin-1 (ISO-8859-1)-tekens. Als u een tekenreeks met Chinese, Japanse, emoji- of andere tekens buiten het Latin-1-bereik doorgeeft, gooit btoa() een DOMException.

UTF-8-veilige codering

Om alle Unicode-tekst correct te verwerken, omhult de tool de native functies:

function encode(text, urlSafe, noPad) {
  let utf8 = encodeURIComponent(text);
  let base64 = btoa(utf8);
  if (urlSafe) base64 = base64.replace(/\+/g, '-').replace(/\//g, '_');
  if (noPad) base64 = base64.replace(/=+$/, '');
  return base64;
}

function decode(base64) {
  let restored = base64.replace(/-/g, '+').replace(/_/g, '/');
  while (restored.length % 4 !== 0) restored += '=';
  let utf8 = atob(restored);
  return decodeURIComponent(utf8);
}

encodeURIComponent converteert de tekst naar UTF-8-procentgecodeerde vorm, die alleen ASCII-tekens bevat die btoa kan verwerken. Het decodeerpad keert dit in omgekeerde volgorde om.

Om te zien waarom dit belangrijk is, probeer de emoji "😊" direct met btoa te coderen — het gooit een fout. Met de UTF-8-omhulling wordt het J UmbKSA4bQ, dat correct terug naar 😊 wordt gedecodeerd.

URL-veilige invoerafhandeling

De decodeerfunctie voert altijd twee transformaties uit voordat de tekenreeks aan atob wordt doorgegeven:

1. Vervang - door + en _ door / (ongedaan maken van URL-veilige codering)
2. Voeg =-padding toe als de tekenreekslengte geen veelvoud van 4 is

Dit betekent dat u nooit een instelling hoeft aan te passen aan de decodeerkant. Of uw invoer nu standaard Base64, URL-veilig Base64, met of zonder padding is, de decoder verwerkt het automatisch.

Gebeurtenisstroom

Wanneer u typt of plakt in een tekstveld, wordt een input-gebeurtenislistener geactiveerd. De planner buffert snelle toetsaanslagen (ontdenderd op ongeveer 16 ms om één frame te raken) en voert vervolgens de codeer- of decodeerfunctie uit. Het resultaat verschijnt in het uitvoertekstveld bij de volgende schermverversing.

Standaard Base64 vs URL-veilig Base64

De twee selectievakjes in het Codeer-gedeelte komen overeen met twee goed gedefinieerde varianten van Base64.

Standaard Base64 (RFC 4648 §4)

Gebruikt het volledige alfabet: A–Z, a–z, 0–9, +, /. Dit is de oorspronkelijke vorm en werkt overal, behalve waar + en / een speciale betekenis hebben.

URL-veilig Base64 (RFC 4648 §5)

Vervangt de twee tekens die problemen veroorzaken in URL's:

Standaard Base64 Pz4/Pj8+QA== wordt Pz4_Pj8- QA_ in URL-veilige vorm (nota: de padding = wordt ook weggelaten in het voorbeeld, hoewel URL-veilig padding kan gebruiken).

Wanneer welke gebruiken

De decodeerkant van deze tool detecteert automatisch welke variant is gebruikt, dus u kunt elk formaat plakken zonder instellingen te wijzigen.

Een veelvoorkomend misverstand

Sommige ontwikkelaars denken dat URL-veilig Base64 een ander algoritme is. Dat is het niet — slechts twee tekens in het alfabet veranderen. Elke standaard Base64-decoder kan worden aangepast door - → + en _ → / te mappen voor verwerking, wat precies is wat deze tool aan de decodeerkant doet.

Padding in Base64-codering

Het =-teken aan het einde van een Base64-tekenreeks is padding — het maakt geen deel uit van de gecodeerde gegevens.

Waarom padding bestaat

Base64 verwerkt invoer in groepen van 3 bytes. Als de laatste groep minder dan 3 bytes heeft, voegt de encoder = toe als padding om de totale lengte een veelvoud van 4 te maken. Dit is vereist door sommige decoders en maakt het mogelijk om meerdere Base64-tekenreeksen zonder dubbelzinnigheid te concatenaten.

Wat "zonder padding" betekent

Wanneer u "Zonder padding" inschakelt, verwijdert de encoder de afsluitende =-tekens uit de uitvoer. Bijvoorbeeld:

• Invoer: Fo → Rm8= (met padding) → Rm8 (zonder padding)
• Invoer: Foo → Rm9v (in beide gevallen geen padding — exact veelvoud van 3)

Veel moderne systemen accepteren Base64 zonder padding, en de decoder van deze tool verwerkt het altijd. Schakel deze optie in wanneer het systeem waarnaar u de uitvoer stuurt geen padding vereist of wenst.

Interoperabiliteitsmatrix

Het decodeergedeelte van deze tool accepteert alle vier combinaties automatisch:

Er is geen instelling om aan te passen. De decoder normaliseert de invoer voor verwerking.

Wanneer padding vereist is

Sommige systemen vereisen strikt padding, met name:

• Data URI's: data:image/png;base64,... — de parser van de browser verwacht correct gepadde Base64.
• Oudere Base64-bibliotheken: Sommige implementaties wijzen invoer zonder padding volledig af.

Als u niet zeker weet of het doelsysteem padding vereist, laat het dan ingeschakeld (standaard). Het verwijderen van padding is alleen veilig wanneer u zowel de encoder als de decoder controleert.

Base64 vs Andere Coderingsschema's

Base64 is een van verschillende binair-naar-tekst coderingsschema's, elk met verschillende afwegingen in dichtheid, alfabetgrootte en gebruiksgeval.

Waarom Base64 het populairst is

Base64 bereikt de sweet spot voor de meeste praktische toepassingen. Vergeleken met Hex — dat de invoergrootte verdubbelt — is de 33 % overhead van Base64 aanzienlijk efficiënter. Vergeleken met Base85 is Base64 eenvoudiger te implementeren (elke taal heeft een ingebouwde decoder), en het alfabet vermijdt de citaatproblemen die Base85-tekens zoals " en \ in sommige contexten kunnen veroorzaken.

Wanneer iets anders gebruiken

• Hex: Wanneer menselijke leesbaarheid en debuggen belangrijker zijn dan grootte. Een Hex-tekenreeks zoals 4f6f is onmiddellijk herkenbaar als gecodeerde gegevens; b293 is minder duidelijk als Base64.
• Base32: Wanneer hoofdletterongevoeligheid vereist is (bijv. om telefonisch door te geven, gedrukt op producten). Base32 gebruikt alleen hoofdletters en cijfers.
• Base85: Wanneer elke byte overhead telt in een beperkt kanaal en u beide uiteinden van de pijplijn controleert.

Voor algemeen webcoderen blijft Base64 de juiste standaardkeuze. Deze tool volgt die conventie.

Prestaties en Grootteoverwegingen

Base64 is eenvoudig en universeel, maar het heeft echte kosten die meetellen wanneer u met grotere gegevens werkt.

De 33 % overhead

Elke 3 bytes invoer worden 4 bytes uitvoer, een verhouding van 4:3. In de praktijk, inclusief padding en regeleinden, is de overhead ongeveer 37 % voor kleine invoer en stabiliseert zich op 33 % voor voldoende grote invoer.

Base64 en compressie

Gzip (of Brotli)-compressie van Base64-tekst is over het algemeen ineffectief. Base64-uitvoer heeft een uniforme tekenverdeling — elk van de 64 tekens verschijnt met ongeveer dezelfde frequentie — wat de patronen elimineert die compressie-algoritmen benutten. Een gecomprimeerde Base64-tekenreeks is vaak slechts 5–10 % kleiner dan de ongecomprimeerde vorm, vergeleken met 60–80 % reductie die haalbaar is met de originele binaire gegevens.

Dit betekent:

• Niet Base64-coderen voordat u comprimeert. Comprimeer eerst, codeer dan indien nodig.
• Vertrouw niet op transportcompressie (bijv. HTTP gzip) om de Base64-overhead te compenseren. Het zal niet.

Wanneer geen Base64 gebruiken

Base64 is zinvol wanneer u binaire gegevens in een tekst-only kanaal moet passen. Als het kanaal native binaire overdracht ondersteunt, sla Base64 dan over:

• Bestandsuploads: Gebruik multipart/form-data met ruwe binaire gegevens, niet Base64 in JSON. Het bestand komt 33 % groter aan op de server en duurt langer om te uploaden.
• Databaseopslag: Sla binaire gegevens op als BYTEA (PostgreSQL), BLOB (MySQL/SQLite) of varbinary (MSSQL) in plaats van Base64-tekst.
• Inter-service API-aanroepen: Gebruik gRPC, Thrift of MessagePack met binaire velden in plaats van Base64-gecodeerde JSON-tekenreeksen.

Voor tekst-payloads (JWT-payloads, HTML-inhoud, e-mailteksten) is de overhead verwaarloosbaar en het gemak van Base64 de afweging waard.

Cache-implicaties

Wanneer u een Base64 Data URI in HTML of CSS inbedt, wordt de gecodeerde inhoud onderdeel van de paginabron. De browser kan die Data URI niet onafhankelijk cachen — elke wijziging aan de pagina maakt deze ongeldig. Een apart afbeeldingsbestand dat via <img src="icon.png"> wordt aangevraagd, kan tussen pagina's worden gecached met een verre Cache-Control-header. Voor assets groter dan een paar kilobyte zijn aparte bestanden bijna altijd beter presterend.

Veelvoorkomende valkuilen en misvattingen

Base64 is eenvoudig, maar verschillende terugkerende misverstanden veroorzaken echte fouten.

Base64 Is Geen Versleuteling

Dit is de meest voorkomende misvatting. Omdat Base64-uitvoer op willekeurige tekens lijkt, nemen veel ontwikkelaars aan dat het enig niveau van bescherming biedt. Dat doet het niet. Decodering vereist geen sleutel of geheim. Behandel elke Base64-tekenreeks als openbaar leesbare tekst.

Als u ziet dat een service wachtwoorden of API-sleutels als Base64 opslaat, behandel dat dan als een beveiligingsprobleem — de gegevens worden in platte tekst opgeslagen.

Hoofdlettergevoeligheid

Het Base64-alfabet maakt onderscheid tussen hoofdletters en kleine letters:

• Hoofdletters: A–Z (waarden 0–25)
• Kleine letters: a–z (waarden 26–51)

Een typefout zoals R vs r verandert de gedecodeerde waarde volledig. Als uw gedecodeerde uitvoer er verkeerd uitziet, controleer dan op hoofdletterfouten in de invoer.

MIME-regeleinden

MIME-gecodeerde e-mailbijlagen breken de Base64-body na elke 76 tekens:

SGVsbG8sIHdvcmxkISBUaGlzIGlzIGEgdGVzdCBvZi BiYXNlNjQgZW5jb2Rpbmcu
VGhpcyBpcyB0aGUgc2Vjb25kIGxpbmUu

Niet alle Base64-decoders verwerken deze ingebedde regeleinden. Deze tool doet dat — plak meerregelig MIME Base64 direct zonder voorbewerking. Een decoder die geen regeleinden verwerkt, produceert een verminkt resultaat of een fout.

Verborgen witruimte

Het kopiëren van tekst uit e-mails, PDF's of webpagina's kan onzichtbare witruimtetekens introduceren (spaties, tabs, nulbreedtetekens, vaste spaties). Deze zijn geen geldige Base64. Als een geldig uitziende Base64-tekenreeks niet decodeert, plak deze dan eerst in een platte teksteditor om te controleren op verborgen tekens, of kopieer opnieuw van de bron.

Concatenatie van strings met padding

Twee Base64-tekenreeksen met padding die direct worden geconcateneerd, decoderen niet noodzakelijk correct. De padding = behoort tot de laatste groep van elke tekenreeks, en concatenatie kan dubbelzinnige grenzen creëren. Dit is opzettelijk — padding voorkomt dubbelzinnigheid voor individuele tekenreeksen. Voor gegevens in meerdere delen, verwerk elk deel afzonderlijk.

Gebruik

Het gebruik van de Base64 Encoder & Decoder vereist geen installatie, registratie of account.

Tekst naar Base64 coderen

1. Typ of plak in het Base64 Coderen-gedeelte uw tekst in het invoertekstveld.
2. Het uitvoerveld werkt automatisch bij met het gecodeerde resultaat.
3. Schakel optioneel URL-veilig in voor de webveilige variant, of Zonder padding om afsluitende =-tekens te verwijderen.
4. Klik op Kopiëren om de gecodeerde tekst naar het klembord te kopiëren, of Base64 downloaden om deze als .b64-bestand op te slaan.

Base64 naar tekst decoderen

1. Plak in het Base64 Decoderen-gedeelte een Base64-tekenreeks in het invoerveld.
2. De gedecodeerde tekst verschijnt onmiddellijk in het uitvoerveld.
3. Als de invoer geen geldige Base64 is, wordt een foutmelding getoond.
4. Klik op Kopiëren of Downloaden om het gedecodeerde resultaat op te slaan.

Bestandsupload gebruiken

• Codeer-gedeelte: sleep een .txt-bestand naar de uploadzone om de inhoud te laden voor codering.
• Decodeer-gedeelte: sleep een .b64- of .txt-bestand om Base64-inhoud te laden voor decodering.

De bestandsinhoud wordt gelezen, in het invoertekstveld geplaatst en onmiddellijk verwerkt.

Handleiding

Scenario: U bouwt een webapplicatie die communiceert met een API. De API verwacht dat de aanvraag-payload een kort tekstveld bevat dat is gecodeerd als URL-veilig Base64 zonder padding. U moet uw tekst coderen, de uitvoer verifiëren en bevestigen dat de API deze accepteert. Later ontvangt u een antwoord van dezelfde API met een Base64-gecodeerd veld dat u moet decoderen.

Deze tutorial leidt u door de volledige ronde.

Deel 1: Coderen

1. Open de Base64 Encoder & Decoder in uw browser. U ziet twee secties naast elkaar — Coderen links, Decoderen rechts.

2. Typ in het Codeer-invoerveld de volgende tekst:

   Hallo, API-server. Dit is mijn payload.
   

   Het uitvoerveld toont onmiddellijk de standaard Base64-codering. Het resultaat begint met SGFsbG8s. Tot zover goed.

3. De API-specificatie vereist URL-veilig Base64 zonder padding. Schakel beide selectievakjes URL-veilig en Zonder padding in. Let op hoe de uitvoer verandert:

   • +-tekens (indien aanwezig) worden -
   • /-tekens worden _
   • Afsluitende =-tekens verdwijnen

4. Klik op Kopiëren om het gecodeerde resultaat naar uw klembord te kopiëren. Plak het in uw API-aanvraag-payload.

Deel 2: Decoderen

5. De API antwoordt met een JSON-payload met een Base64-gecodeerd veld:

   {
     "status": "ok",
     "message": "eyJzdWIiOiAiMTAwMSIsICJuYW1lIjogIkFQSSBHYXRld2F5In0="
   }
   

6. Kopieer de waarde van message en plak deze in het Decodeer-invoerveld.

   Het uitvoerveld toont onmiddellijk de gedecodeerde tekst:

   { "sub": "1001", "name": "API Gateway" }
   

7. De JWT-achtige JSON-payload is nu leesbaar. Als de API URL-veilig Base64 had gebruikt (geen + of / in de tekenreeks, of met - en _), zou de decoder het automatisch hebben verwerkt.

Deel 3: Bestandsgebaseerde workflow

8. Stel dat u de gecodeerde payload naar een collega moet sturen die de voorkeur geeft aan bestanden. Klik op Base64 downloaden in het Codeer-gedeelte. De Opslaan als-dialoog van uw browser opent, met download.b64 als voorgestelde bestandsnaam. Sla het bestand op.

9. Uw collega ontvangt het bestand en opent dezezelfde tool. Hij sleept download.b64 naar de uploadzone van het Decodeer-gedeelte. De bestandsinhoud verschijnt in het invoerveld en de gedecodeerde tekst verschijnt onmiddellijk.

Deze ronde — coderen met opties → kopiëren of downloaden → decoderen met automatische detectie — dekt de meest voorkomende real-world workflow. De tool verzorgt alle normalisatie, zodat u niet hoeft na te denken over tekenvarianten of paddingregels.

Pro-tips

• Gelijktijdig coderen en decoderen: De twee secties zijn onafhankelijk. U kunt tekst typen in het Codeer-gedeelte en tegelijkertijd een aparte Base64-tekenreeks plakken in het Decodeer-gedeelte. Gebruik dit om invoer en uitvoer van beide richtingen naast elkaar te vergelijken.

• URL-veilig voor JWT's: Schakel bij het werken met JWT-tokens altijd de URL-veilige modus in. JWT-segmenten gebruiken de URL-veilige variant (RFC 7515). Als u een JWT-segment in het decodeergedeelte plakt, detecteert de tool de URL-veilige tekens automatisch.

• Verwijder witruimte voor het plakken: Sommige bronnen van Base64-gegevens bevatten afsluitende regeleinden of spaties. De decoder verwerkt opgeschoonde invoer het beste. Als u een "Ongeldige Base64-tekenreeks"-fout ziet, controleer dan of de geplakte tekst extra witruimte bevat.

• Download voor grote uitvoer: Gebruik voor lange Base64-tekenreeksen de Download-knoppen in plaats van Kopiëren. De native Opslaan als-dialoog laat u kiezen waar u het bestand opslaat, en het resultaat wordt opgeslagen als een .b64- of .txt-bestand dat u kunt overdragen of archiveren.

• Upload als alternatief voor typen: Als u al een bestand met de tekst of Base64-gegevens heeft, sleep het dan naar de uploadzone. Dit is sneller dan het bestand openen, alles selecteren, kopiëren en plakken — vooral voor grote bestanden.

• Decodeer eerst om het formaat te controleren: Als u een Base64-tekenreeks ontvangt en niet zeker weet of deze tekst of binaire gegevens bevat, plak deze dan in het decodeergedeelte. Als de uitvoer leesbare tekst is, bent u klaar. Als deze verminkte tekens of vervangende glyphs ( ) bevat, was de oorspronkelijke bron waarschijnlijk binair (een afbeelding, PDF of ander niet-tekstformaat).

Alternatieven

Er zijn verschillende andere manieren om Base64 te coderen of decoderen, elk met verschillende afwegingen.

Voor het coderen of decoderen van Base64-tekst met privacy, real-time feedback en geen kennis van de opdrachtregel, biedt deze tool de beste gebruikerservaring.

Gegevensprivacy

De Base64 Encoder & Decoder verwerkt elk teken volledig in uw browser. Geen tekst die u invoert, wordt verzonden naar een server, opgeslagen in een database of gelogd in een systeem.

Alle conversie wordt uitgevoerd met behulp van JavaScript's native btoa()- en atob()-functies in het browsergeheugen. De pagina bevat geen analytics-scripts, tracking-pixels of third-party insluitingen. Er worden geen cookies, localStorage- of sessionStorage-items gemaakt of gelezen.

Na het eerste laden van de pagina werkt de tool volledig offline. U kunt de internetverbinding verbreken en doorgaan met coderen en decoderen zonder onderbreking. Controleer dit door de tool in vliegtuigmodus te gebruiken of door netwerkactiviteit te inspecteren in de ontwikkeltools van uw browser — er verlaten geen verzoeken uw apparaat nadat de pagina is geladen.

Probleemoplossing

Technische Specificaties

• Kernalgoritme: btoa() / atob() omhuld met encodeURIComponent / decodeURIComponent voor UTF-8-veiligheid
• Standaard: RFC 4648 §4 (standaard Base64), RFC 4648 §5 (URL-veilig Base64)
• Invoerafhandeling: Automatische URL-veilige tekenconversie (- → +, _ → /) en padding-normalisatie bij decodering
• Real-time Verwerking: input-gebeurtenislistener op tekstvelden, ontdenderd op ongeveer één frame (16 ms)
• Bestands-I/O: FileReader-API voor upload, showSaveFilePicker (File System Access API) met <a download>-fallback
• Downloadformaten: .b64 (gecodeerd), .txt (gedecodeerd)
• Uploadformaten: .txt (Codeer-gedeelte), .b64 / .txt (Decodeer-gedeelte)

Prestatiebenchmarks

Gemeten op een middenklasse laptop uit 2020 (Chrome 120). Prestaties schalen lineair met de invoergrootte. Voor typische tekst-payloads onder 100 KB is de conversie praktisch onmiddellijk.

Browsercompatibiliteit

showSaveFilePicker vereist Chromium-gebaseerde browsers (Chrome, Edge, Opera, Samsung Internet). In Firefox en Safari valt de download automatisch terug op de <a download>-methode.

Privacy en Beveiliging

• Nul gegevensoverdracht: alle tekstverwerking vindt plaats in het browsergeheugen
• Geen cookies, localStorage of sessionStorage gebruikt
• Geen analyse- of tracking-scripts op de toolpagina
• Volledig functioneel in offlinemodus na het eerste laden van de pagina
• Geen registratie, login of API-sleutels vereist

Functies

• Tekst naar Base64 encoderen en Base64 terug naar tekst decoderen met real-time conversie
• URL-veilige modus met -_ in plaats van +/ voor webvriendelijk Base64 (RFC 4648 §5)
• Zonder-padding-optie om afsluitende gelijktekens te verwijderen (RFC 4648 §3.2)
• Ingebouwde uitleg van het Base64-coderingsschema en het .b64-bestandsformaat
• .txt- en .b64-bestanden uploaden met sleepondersteuning
• Resultaten downloaden als .b64- of .txt-bestanden met native Opslaan als-dialoog
• Volledig client-side — geen serveruploads, werkt offline

Veelgestelde vragen