> base64 encoder | tekst | bestand <

Typ of plak je tekst in het INVOER-gebied hierboven. Automatisch coderen staat standaard aan — het Base64-resultaat verschijnt tijdens het typen in het UITVOER-vak. Klik op [ENCODE] of druk op Ctrl/Cmd + Enter om de codering handmatig te starten. Schakel --url-safe of --no-padding in, afhankelijk van waar de Base64 wordt gebruikt (JWT, OAuth, URL's → beide aan). Alles draait lokaal in je browser: geen uploads, geen logs, geen netwerkverzoeken gekoppeld aan je invoer.

Klik op de knop [upload file] onder het invoergebied en kies een bestand tot 100 MB. De encoder leest het met FileReader.readAsArrayBuffer, stuurt de bytes via btoa in stukken van 32 KB door (zodat grote bestanden de browser niet laten crashen) en schrijft de volledige Base64 in het UITVOER-vak. Gebruik voor grotere bestanden een opdrachtregel-encoder: base64 < input.bin > output.txt (macOS/Linux), of PowerShell: [Convert]::ToBase64String([IO.File]::ReadAllBytes('input.bin')).

Als je de Base64 als Data URI wilt opmaken (bijv. data:image/png;base64,...), zet dan het MIME-type en ;base64, voor de uitvoer, of gebruik onze speciale Afbeelding naar Base64-tool, die kant-en-klare Data URI's levert voor PNG, JPG, GIF, WebP en SVG.

Alle drie zijn gedefinieerd in RFC 4648:

• Standaard-Base64 (§4) gebruikt het alfabet A-Z a-z 0-9 + / met =-padding. De uitvoerlengte is altijd een veelvoud van 4. Veilig voor MIME, HTTP Basic Auth en JSON-stringwaarden.

• URL-veilige Base64 (§5) vervangt + door - en / door _. Vereist wanneer Base64 in URL-paden, queryparameters, bestandsnamen of JWT-segmenten wordt geplaatst — de standaardtekens +/ zouden anders percent-gecodeerd moeten worden.

• Geen padding (zowel §4 als §5, base64url zonder padding) laat afsluitende =-tekens weg. De lengte is niet langer een veelvoud van 4, maar decoders kunnen de oorspronkelijke lengte berekenen uit de rest modulo 4. Gebruikt door JWT (base64url volgens RFC 7515), WebAuthn en sommige CBOR/COSE-implementaties.

Decoders moeten weten welke variant ze kunnen verwachten — onze Base64-decoder detecteert alle drie automatisch.

Elke belangrijke taal en runtime wordt geleverd met Base64-codering. Kant-en-klare snippets om te kopiëren en plakken:

JavaScript (browser):
btoa('Hello') // SGVsbG8=
// Voor UTF-8:
btoa(String.fromCharCode(...new TextEncoder().encode(s))) // UTF-8-veilig

Node.js:
Buffer.from('Hello', 'utf-8').toString('base64') // SGVsbG8=
Buffer.from(bytes).toString('base64url') // URL-veilig, geen padding

Python:
import base64
base64.b64encode(b'Hello').decode() # SGVsbG8=
base64.urlsafe_b64encode(b'Hello').decode().rstrip('=') # URL-veilig, geen padding

PHP: base64_encode('Hello')
Ruby: Base64.strict_encode64('Hello') / Base64.urlsafe_encode64('Hello')
Go: base64.StdEncoding.EncodeToString([]byte("Hello")) / base64.URLEncoding.EncodeToString(...) / base64.RawURLEncoding.EncodeToString(...) (geen padding)
Java: Base64.getEncoder().encodeToString("Hello".getBytes(StandardCharsets.UTF_8))
C#: Convert.ToBase64String(Encoding.UTF8.GetBytes("Hello"))
Rust: base64::engine::general_purpose::STANDARD.encode("Hello")

Shell (macOS/Linux): echo -n 'Hello' | base64 → SGVsbG8=. Gebruik base64 -w 0 op Linux om de regelafbreking bij 76 kolommen te onderdrukken.

Base64-uitvoer is ~33% groter dan de invoer: elke 3 invoerbytes worden 4 uitvoertekens. Exacte formule: ceil(n / 3) × 4 inclusief padding, of ceil(n × 4 / 3) zonder. Plus enkele bytes extra overhead als je regels afbreekt bij 76 kolommen (MIME) of 64 kolommen (PEM).

Voorbeelden:
• 1 KB binair → ~1,37 KB Base64
• 100 KB afbeelding → ~137 KB Data URI
• 1 MB PDF → ~1,37 MB Base64 in JSON

Wanneer Base64 te vermijden:
• Grote bestandsoverdrachten: een afbeelding van 10 MB ingesloten als Base64 in HTML wordt 13,7 MB geparste tekst, blokkeert de hoofdthread en kan niet apart worden gecachet. Geef de voorkeur aan <img src="/assets/photo.png">.
• Prestatiekritische API's: een Base64-payload van 500 KB in JSON wordt ~2-3× langzamer geparst dan een equivalent binair endpoint.
• Als beveiligingsmaatregel: Base64 is geen versleuteling — iedereen kan het decoderen. Gebruik AES-GCM of vergelijkbaar voor vertrouwelijkheid.
• Database-BLOB's: sla ruwe bytes op als BLOB/BYTEA, niet als Base64-tekst, om 33% opslag te besparen en codeer/decodeer-cycli te vermijden.

JWT (RFC 7515) en OAuth PKCE (RFC 7636) gebruiken beide URL-veilige Base64 zonder padding, vaak base64url genoemd. Om het in deze tool te produceren: schakel zowel het selectievakje --url-safe als --no-padding in en codeer vervolgens je tekst.

Programmatische equivalenten:
• JavaScript: btoa(s).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')
• Node.js: Buffer.from(s).toString('base64url')
• Python: base64.urlsafe_b64encode(s.encode()).decode().rstrip('=')
• Go: base64.RawURLEncoding.EncodeToString([]byte(s))
• Java: Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)

Veelvoorkomende JWT-velden die base64url nodig hebben: de drie door punten gescheiden segmenten (header, payload, handtekening), OAuth PKCE code_verifier/code_challenge, WebAuthn-challenges, Web Push p256dh/auth-sleutels en Googles Request.state-parameters.

Een veelvoorkomende bug is het verzenden van een JWT met standaard-Base64 (+/) — API's wijzen het af als onjuist omdat de + tijdens het transport URL-gedecodeerd wordt naar een spatie.

Ja, met één kanttekening. Deze encoder produceert het Base64-gedeelte van een Data URI — het deel na ;base64,. Om een volledige Data URI te bouwen, zet je voorop:

data:<mime-type>;base64,<encoded-output>

Veelvoorkomende MIME-types:
• data:image/png;base64,... — PNG-afbeelding
• data:image/jpeg;base64,... — JPEG-afbeelding
• data:image/svg+xml;base64,... — SVG (of gebruik data:image/svg+xml;utf8, zonder Base64 — meestal kleiner)
• data:application/pdf;base64,... — PDF-bestand
• data:application/font-woff2;base64,... — lettertype insluiten
• data:text/plain;charset=utf-8;base64,... — in Base64 verpakte tekst

Voor afbeeldingen en SVG's geeft de Afbeelding naar Base64-tool de volledige Data URI uit, klaar om te plakken in CSS background-image, inline <img src="..."> of <object data="...">-tags.

Groottewaarschuwing: Data URI's boven 20-30 KB schaden de LCP (Largest Contentful Paint) omdat de browser ze niet vooraf kan laden — houd inline Base64-afbeeldingen klein en geef de voorkeur aan een gewone <img> met loading="lazy" voor grotere assets.

Ja — niets verlaat je browser. De encoder draait volledig in JavaScript met de native API's btoa(), TextEncoder en FileReader. Er zijn geen netwerkaanroepen op de inhoud van de invoer, geen telemetrie, geen logging, geen analyses van derden op wat je codeert. Je kunt het Network-tabblad in DevTools openen tijdens het coderen en nul gerelateerde verzoeken waarnemen.

Echter, Base64 is geen versleuteling — het is een omkeerbare codering, en iedereen met de uitvoer kan het decoderen. Dus:
• Plak geen productiegeheimen in chat, screenshots of logs, zelfs niet in gecodeerde vorm.
• Voor HTTP Basic Auth is de Base64-header Authorization: Basic alleen veilig via TLS (HTTPS). Via gewone HTTP is hij triviaal af te luisteren.
• Gebruik voor echte vertrouwelijkheid AES-GCM, age, sops of een KMS — codeer vervolgens indien nodig de versleutelde tekst in Base64 voor transport.

Voor strikt beleid tegen data-exfiltratie kun je deze pagina offline opslaan (Cmd/Ctrl + S). De encoder werkt na één keer laden volledig air-gapped, omdat er geen serverafhankelijkheid is.

De encoder ondersteunt bestanden tot 100 MB via de harde limiet in de bestandshandler — groot genoeg voor de meeste afbeeldingen, PDF's, ZIP-archieven en zelfs korte video's. Prestatiedoelen:

• < 1 MB: codering voltooid in <50 ms, geen UI-bevriezing.
• 1 – 10 MB: 100-500 ms afhankelijk van de CPU. De browser blijft responsief omdat we coderen in stukken van 32 KB.
• 10 – 100 MB: 2-15 seconden. Het uitvoer-tekstgebied kan iets traag worden bij het plakken/scrollen van zulke enorme Base64-strings. Overweeg de uitvoer indien nodig als .txt-bestand te downloaden vanuit DevTools.
• > 100 MB: geblokkeerd — de geheugenoverhead van de browser (invoerbytes + binaire string + Base64-string ≈ 3-4× de bestandsgrootte) brengt het risico van tabcrashes met zich mee. Gebruik:

# macOS / Linux
base64 -i huge.bin -o huge.b64

# Windows PowerShell
$bytes = [IO.File]::ReadAllBytes('huge.bin')
[IO.File]::WriteAllText('huge.b64', [Convert]::ToBase64String($bytes))

Voor streaming-/multi-GB-workflows, zie grote bestanden naar Base64 coderen voor een chunked aanpak met Node.js/Python die voorkomt dat alles in het geheugen wordt geladen.

Deze encoder gebruikt UTF-8, dezelfde codering die standaard wordt gebruikt door het moderne web, JSON, Linux, macOS en bijna alle programmeertalen. Onder de motorkap wordt tekst door new TextEncoder().encode(input) geleid, wat altijd UTF-8-bytes produceert, en pas daarna in Base64 gecodeerd.

Waarom dit belangrijk is: de oudere JavaScript-functie btoa() verwerkt alleen Latin-1 en gooit InvalidCharacterError bij tekens zoals é, 中 of 😀. Onze wrapper regelt de UTF-8-conversie voor je, zodat emoji, Chinees, Japans, Koreaans, Arabisch, Cyrillisch en elk Unicode-codepunt correct worden gecodeerd.

Als je een andere codering nodig hebt:
• UTF-16 LE (Windows-native): zeldzaam — meestal een teken van legacy-interoperabiliteit. Gebruik toch new TextEncoder({ fatal: true }).encode(s) en converteer stroomopwaarts.
• ISO-8859-1 / Latin-1: wijs codepunten 0-255 handmatig toe aan bytes vóór de codering.
• GB18030, Shift_JIS, EUC-KR: gebruik een bibliotheek zoals iconv-lite in Node.js om eerst te transcoderen.

Een subtiele valkuil: als je brongegevens al in een niet-UTF-8-codering staan (bijv. bij het lezen van een legacy-MySQL-dump), decodeer ze dan eerst met de juiste codec, codeer ze vervolgens opnieuw naar UTF-8 voordat je Base64 toepast — anders behoudt de gedecodeerde Base64 de mojibake.