Waarom maakt Base64 bestanden groter?

Dit artikel legt uit waarom Base64-uitvoer groter is dan de oorspronkelijke bytes. Het is geen beveiligingsgids. Als je codering versus encryptie nodig hebt, gebruik Base64 is geen encryptie: wat het écht doet en hoe je decodeert.

Waarom heeft Base64 meer ruimte nodig?

3 bytes zijn 24 bits. Base64 splitst die 24 bits in 4 groepen van 6 bits. Elke groep wordt één Base64-teken, dus 3 invoerbytes worden 4 uitvoertekens. Opgeslagen als 1 byte per ASCII-teken is dat 4 / 3 ≈ 1.333 — ongeveer 33.3% toename.

• 3 bytes (24 bits)
• ↓
• Splitsen in 4 groepen van 6 bits
• Elke groep → één Base64-teken
• ↓
• 4 tekens (vaak 4 bytes tekst)

Een eenvoudig, controleerbaar voorbeeld

Deze coderingen komen overeen met standaard Base64 met padding.

Man

Man

Base64

TWFu

Man is 3 UTF-8/ASCII-bytes. TWFu is 4 tekens: 3 → 4.

Hello

Hello

Base64

SGVsbG8=

Hello is 5 bytes. SGVsbG8= is 8 tekens, inclusief één =. Bij kleine data laat padding het percentage groter lijken dan 33%.

Hoe bereken je de Base64-grootte?

Voor standaard Base64 met padding geldt encodedLength = 4 × ceil(originalBytes / 3).

Oorspronkelijke bytes	Base64-tekens
1	4
2	4
3	4
4	8
5	8
6	8

1 of 2 bytes leveren toch 4 tekens op. Gebruik de formule, niet een vast 33%.

Wat betekent de “=”-padding?

Het =-teken toont dat het laatste 3-byteblok niet vol was. 1 invoerbyte gebruikt twee =-tekens; 2 bytes één; 3 bytes geen. Padding is geen encryptie en geen beveiligingsfunctie.

Gebruikt Base64URL minder ruimte?

Base64URL verandert + in - en / in _, en Base64 coderen laat trailing = bij encoderen weg. Dat kan de string inkorten met die =-tekens. De structuur 3 bytes → 4 tekens blijft, dus Base64URL is geen ruimtezuiniger binair formaat.

Waarom kan minuscule invoer met meer dan 33% groeien?

1 byte → 4 tekens is 300% lengtetoename. 2 bytes → 4 is 100%. 3 bytes → 4 is ongeveer 33.3%. Naarmate n groeit, telt padding minder en nadert de extra kost ongeveer 33%. Base64 is niet in elk geval 33% groter.

Waarom is een Base64-Data-URL nóg groter?

Een Data URL voegt een prefix zoals data:image/png;base64, toe vóór de payload. Bij een minuscuul bestand kan die prefix het percentage overheersen. Base64 coderen kan ruwe Base64 of een Data URL uitgeven; Data-URL-uitvoer gebruikt het standaardalfabet.

Base64 vs binair: wat is kleiner?

Ruwe binaire data is ruimtezuiniger voor transport en opslag. Base64 is groter, maar tekstveilig in JSON, e-mail en andere paden met alleen tekst. Het is binair-naar-tekstcodering, geen compressie.

Comprimeert Base64 bestanden?

Nee. Base64 is geen compressieformaat. De gecodeerde tekst is meestal groter dan de oorspronkelijke bytes. Als je later gzip of Brotli op die tekst toepast, kan wat redundantie krimpen — het resultaat hangt af van de data en de compressor. gzip verwijdert de Base64-extra niet volledig.

Wat gebeurt er als Base64 gzip krijgt?

HTTP-compressie kan sommige herhaalde patronen in Base64-tekst verminderen. JPEG, PNG of ZIP comprimeren vaak slecht, zelfs als ruwe bytes, en Base64-dan-gzip blijft gevalafhankelijk. Er is geen universeel extra-percentage na gzip.

Moet je bestanden als Base64 opslaan?

Base64 kan binair in een JSON-veld, een klein inline-asset, een API die alleen tekst toestaat, kopiëren/plakken of een Data URL passen. Bij grote bestanden groeien opslag, geheugen en payloadgrootte allemaal. Dat is niet “gebruik nooit Base64 voor bestanden”.

Waarom is Base64 gebruikelijk in JSON-API’s?

JSON heeft geen native ruwe-binairtype, dus API’s zetten bytes vaak in een Base64-string. Voor grote bestanden kunnen multipart/form-data, objectopslag of een directe binaire upload beter passen. Geen keuze is altijd de beste.

Waarom wordt Base64 in e-mail gebruikt?

MIME kan Base64 gebruiken zodat een binaire bijlage als tekstveilige tekens reist. Dezelfde grootte-extra blijft gelden. Dit is een transportweergave, geen kleiner bestand.

Wanneer is de extra grootte de moeite waard?

De extra grootte kan de moeite waard zijn wanneer binair in tekst moet, de payload klein is, een API Base64 eist, of je een Data URL nodig hebt. Voor grote media, kies ruwe binaire data als het systeem dat toestaat.

Wanneer moet je Base64 vermijden?

Sla het over bij grote bestanden, krappe bandbreedte, frequente transfers, of wanneer er al een binair pad is — situationeel, niet “Base64 is slechte praktijk”.

Base64-lengtes met padding die je kunt controleren

Oorspronkelijke bytetellingen en tekentellingen van standaard Base64 met padding:

Oorspronkelijke bytes	Base64-tekens
1	4
2	4
3	4
10	16
100	136
1,000	1,336

Alle rijen volgen 4 × ceil(n / 3). Dit zijn Base64-tekentellingen.

Voorbeeld: hoe groot wordt een bestand van 1,000 bytes?

4 × ceil(1000 / 3). ceil(333.333…) = 334, en 4 × 334 = 1336. Dus 1,000 bytes worden 1,336 Base64-tekens. Opgeslagen als UTF-8/ASCII is elk teken typisch 1 byte — behandel 1,336 niet als een exacte bytetelling in het geheugen.

Kan Base64 meer geheugen gebruiken dan de bestandsgrootte suggereert?

Sommige runtimes slaan strings op met meer dan 1 byte per teken, en encoderen/decoderen kan een buffer en een string tegelijk vasthouden. Geheugengebruik is niet exact de tekenlengte.

Een eenvoudige grootte-beslisgids

Als het systeem ruwe binaire data accepteert, geef die de voorkeur omwille van grootte. Als alleen tekst mag, kan Base64 passen. Bij een grote payload, zoek een binair uploadpad. Voor URL-veilige tekst, overweeg Base64URL — de 3-naar-4-expansie blijft.

• Binaire data moeten versturen
• ↓
• Ruwe binaire data toegestaan? Kies binair omwille van grootte
• Alleen-tekstveld? Base64 kan passend zijn
• Grote payload? Zoek een binair uploadpad
• URL-veilige tekst nodig? Overweeg Base64URL
• ↓
• Verwacht ongeveer 33% meer tekst bij grote invoer

Base64 encoderen of decoderen in je browser

NEXNARA Base64 coderen encodeert en decodeert tekst, en kan een bestand in Base64 of een Data URL omzetten en Base64 weer tot een bestand maken.

Tekst gebruikt UTF-8-bytes, daarna Base64 — niet alleen ASCII. Kies Standard of Base64URL. Bestandsuitvoer kan ruwe Base64 of een Data URL zijn (standaardalfabet). Ongeldige invoer wordt geweigerd. Niet-UTF-8-bytes moeten naar bestand, niet naar tekstdecode.

Bestanden boven 10 MB kunnen het tabblad vertragen (waarschuwing). Bestanden boven 32 MB worden geblokkeerd.

Encoderen en decoderen gebeuren in je browser. Het bestand wordt voor deze tool niet naar een NEXNARA-server gestuurd. Advertenties en andere sitefuncties gebruiken nog steeds het netwerk.

Plak tekst of een bestand in Base64 coderen en vergelijk oorspronkelijke bytes met de gecodeerde lengte.

FAQ

Waarom vergroot Base64 de bestandsgrootte?

Het mapt 3 bytes (24 bits) op 4 tekens (4 × 6 bits). Als tekst opgeslagen is dat bij grote invoer ongeveer een derde meer.

Is Base64 altijd 33% groter?

Nee. Grote invoer nadert ongeveer 33.3%. Minuscule invoer kan door padding meer groeien. Gebruik 4 × ceil(n / 3).

Hoeveel groter is Base64 dan binair?

De standaardlengte met padding is 4 × ceil(n / 3) tekens. Een Data-URL-prefix voegt meer toe.

Vermindert Base64-compressie de bestandsgrootte?

Base64 comprimeert niet. gzip of Brotli op de gecodeerde tekst kunnen een deel laten krimpen; ze wissen de extra niet in elk geval.

Gebruikt Base64URL minder ruimte?

Het kan =-padding weglaten, dus de string kan 0–2 tekens korter zijn. De 3-naar-4-codeerstructuur is hetzelfde.

Moet ik Base64 voor grote bestanden gebruiken?

Alleen als je tekst nodig hebt. Bij grote of frequente transfers is een binair pad vaak kleiner. Base64 is voor API’s niet altijd fout.