> base64 encoder | text | datei <

Tippen oder fügen Sie Ihren Text in den EINGABE-Bereich oben ein. Auto-Kodierung ist standardmäßig aktiviert — das Base64-Ergebnis erscheint beim Tippen im AUSGABE-Feld. Klicken Sie [ENCODE] oder drücken Sie Strg/Cmd + Enter, um die Kodierung manuell auszulösen. Aktivieren Sie --url-safe oder --no-padding je nachdem, wo das Base64 verwendet wird (JWT, OAuth, URLs → beide an). Alles läuft lokal in Ihrem Browser: keine Uploads, keine Logs, keine Netzwerkanfragen an Ihre Eingabe gekoppelt.

Klicken Sie auf die Schaltfläche [upload file] unterhalb des Eingabebereichs und wählen Sie eine Datei bis 100 MB aus. Der Encoder liest sie mit FileReader.readAsArrayBuffer, streamt die Bytes in 32-KB-Chunks durch btoa (damit große Dateien den Browser nicht zum Absturz bringen) und schreibt das vollständige Base64 in das AUSGABE-Feld. Für größere Dateien verwenden Sie einen Kommandozeilen-Encoder: base64 < input.bin > output.txt (macOS/Linux) oder PowerShell: [Convert]::ToBase64String([IO.File]::ReadAllBytes('input.bin')).

Wenn Sie das Base64 als Data URI (z. B. data:image/png;base64,...) formatiert haben möchten, stellen Sie den MIME-Typ und ;base64, der Ausgabe voran, oder nutzen Sie unser spezielles Bild-zu-Base64-Tool, das fertig einfügbare Data URIs für PNG, JPG, GIF, WebP und SVG liefert.

Alle drei sind in RFC 4648 definiert:

• Standard-Base64 (§4) verwendet das Alphabet A-Z a-z 0-9 + / mit =-Padding. Die Ausgabelänge ist immer ein Vielfaches von 4. Sicher für MIME, HTTP Basic Auth und JSON-String-Werte.

• URL-sicheres Base64 (§5) ersetzt + durch - und / durch _. Erforderlich, wenn Base64 in URL-Pfaden, Query-Parametern, Dateinamen oder JWT-Segmenten platziert wird — die Standardzeichen +/ müssten sonst Prozent-kodiert werden.

• Kein Padding (sowohl §4 als auch §5, base64url unpadded) lässt abschließende =-Zeichen weg. Die Länge ist dann kein Vielfaches von 4 mehr, aber Decoder können die ursprüngliche Länge aus dem Rest modulo 4 berechnen. Wird von JWT (base64url gemäß RFC 7515), WebAuthn und manchen CBOR/COSE-Implementierungen verwendet.

Decodern muss mitgeteilt werden, welche Variante zu erwarten ist — unser Base64-Decoder erkennt alle drei automatisch.

Jede größere Sprache und Laufzeitumgebung bringt Base64-Kodierung mit. Kopierfertige Snippets:

JavaScript (Browser):
btoa('Hello') // SGVsbG8=
// Für UTF-8:
btoa(String.fromCharCode(...new TextEncoder().encode(s))) // UTF-8 sicher

Node.js:
Buffer.from('Hello', 'utf-8').toString('base64') // SGVsbG8=
Buffer.from(bytes).toString('base64url') // URL-sicher, kein Padding

Python:
import base64
base64.b64encode(b'Hello').decode() # SGVsbG8=
base64.urlsafe_b64encode(b'Hello').decode().rstrip('=') # URL-sicher, kein 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(...) (kein 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=. Verwenden Sie base64 -w 0 unter Linux, um den 76-Spalten-Zeilenumbruch zu unterdrücken.

Die Base64-Ausgabe ist ~33 % größer als die Eingabe: Aus jeweils 3 Eingabebytes werden 4 Ausgabezeichen. Exakte Formel: ceil(n / 3) × 4 inklusive Padding oder ceil(n × 4 / 3) ohne. Hinzu kommen einige weitere Bytes Overhead, wenn Sie bei 76 Spalten (MIME) oder 64 Spalten (PEM) umbrechen.

Beispiele:
• 1 KB binär → ~1,37 KB Base64
• 100 KB Bild → ~137 KB Data URI
• 1 MB PDF → ~1,37 MB Base64 in JSON

Wann Base64 vermeiden:
• Große Dateiübertragungen: Ein 10-MB-Bild, als Base64 in HTML eingebettet, wird zu 13,7 MB geparstem Text, blockiert den Haupt-Thread und kann nicht separat gecacht werden. Bevorzugen Sie <img src="/assets/photo.png">.
• Performance-kritische APIs: Eine 500-KB-Base64-Payload in JSON wird ~2–3× langsamer geparst als ein äquivalenter Binär-Endpunkt.
• Als Sicherheitsmaßnahme: Base64 ist keine Verschlüsselung — jeder kann es dekodieren. Verwenden Sie AES-GCM oder Ähnliches für Vertraulichkeit.
• Datenbank-BLOBs: Speichern Sie Rohbytes als BLOB/BYTEA, nicht als Base64-Text, um 33 % Speicher zu sparen und Kodier-/Dekodier-Umläufe zu vermeiden.

JWT (RFC 7515) und OAuth PKCE (RFC 7636) verwenden beide URL-sicheres Base64 ohne Padding, oft base64url genannt. Um es in diesem Tool zu erzeugen: Aktivieren Sie sowohl die Checkbox --url-safe als auch --no-padding und kodieren Sie dann Ihren Text.

Programmatische Entsprechungen:
• 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)

Häufige JWT-Felder, die base64url benötigen: die drei durch Punkte getrennten Segmente (Header, Payload, Signatur), OAuth PKCE code_verifier/code_challenge, WebAuthn-Challenges, Web-Push-Schlüssel p256dh/auth und Googles Request.state-Parameter.

Ein häufiger Fehler ist, ein JWT mit Standard-Base64 (+/) zu senden — APIs weisen es als fehlerhaft zurück, weil das + während der Übertragung URL-dekodiert zu einem Leerzeichen wird.

Ja, mit einer Einschränkung. Dieser Encoder erzeugt den Base64-Teil einer Data URI — den Teil nach ;base64,. Um eine vollständige Data URI zu bauen, stellen Sie voran:

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

Häufige MIME-Typen:
• data:image/png;base64,... — PNG-Bild
• data:image/jpeg;base64,... — JPEG-Bild
• data:image/svg+xml;base64,... — SVG (oder data:image/svg+xml;utf8, ohne Base64 — meist kleiner)
• data:application/pdf;base64,... — PDF-Datei
• data:application/font-woff2;base64,... — Font-Embed
• data:text/plain;charset=utf-8;base64,... — Base64-umhüllter Text

Für Bilder und SVGs gibt das Bild-zu-Base64-Tool die komplette Data URI aus, bereit zum Einfügen in CSS background-image, inline <img src="..."> oder <object data="...">-Tags.

Größen-Warnung: Data URIs über 20–30 KB schaden dem LCP (Largest Contentful Paint), weil der Browser sie nicht vorladen kann — halten Sie inline Base64-Bilder klein und bevorzugen Sie reguläres <img> mit loading="lazy" für größere Assets.

Ja — nichts verlässt Ihren Browser. Der Encoder läuft vollständig in JavaScript über die nativen APIs btoa(), TextEncoder und FileReader. Es gibt keine Netzwerkaufrufe auf den Eingabeinhalt, keine Telemetrie, kein Logging, keine Drittanbieter-Analytics auf das, was Sie kodieren. Sie können während der Kodierung den Netzwerk-Tab in den DevTools öffnen und null zugehörige Anfragen beobachten.

Allerdings ist Base64 keine Verschlüsselung — es ist eine umkehrbare Kodierung, und jeder mit der Ausgabe kann sie dekodieren. Also:
• Fügen Sie keine Produktionsgeheimnisse in Chat, Screenshots oder Logs ein, selbst in kodierter Form.
• Für HTTP Basic Auth ist der Base64-Header Authorization: Basic nur über TLS (HTTPS) sicher. Über Klartext-HTTP ist er trivial abhörbar.
• Für echte Vertraulichkeit verwenden Sie AES-GCM, age, sops oder ein KMS — und Base64-kodieren den Chiffretext bei Bedarf für den Transport.

Für strenge Datenabflussrichtlinien speichern Sie diese Seite offline (Cmd/Strg + S). Der Encoder funktioniert nach einem Laden vollständig luftdicht, da es keine Serverabhängigkeit gibt.

Der Encoder unterstützt Dateien bis 100 MB über das harte Limit im Datei-Handler — groß genug für die meisten Bilder, PDFs, ZIP-Archive und sogar kurze Videos. Performance-Ziele:

• < 1 MB: Kodierung in <50 ms abgeschlossen, kein UI-Einfrieren.
• 1 – 10 MB: 100–500 ms je nach CPU. Der Browser bleibt reaktionsfähig, weil wir in 32-KB-Chunks kodieren.
• 10 – 100 MB: 2–15 Sekunden. Das Ausgabe-Textfeld kann beim Einfügen/Scrollen solch riesiger Base64-Strings leicht hängen. Erwägen Sie bei Bedarf, die Ausgabe als .txt-Datei aus den DevTools herunterzuladen.
• > 100 MB: blockiert — der Browser-Speicher-Overhead (Eingabebytes + Binärstring + Base64-String ≈ 3–4× die Dateigröße) birgt Tab-Absturzrisiken. Verwenden Sie:

# 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))

Für Streaming-/Multi-GB-Workflows siehe große Dateien zu Base64 kodieren für einen Chunked-Ansatz mit Node.js/Python, der vermeidet, alles in den Speicher zu laden.

Dieser Encoder verwendet UTF-8, dieselbe Kodierung, die vom modernen Web, JSON, Linux, macOS und nahezu allen Programmiersprachen standardmäßig genutzt wird. Intern wird Text durch new TextEncoder().encode(input) geleitet, was stets UTF-8-Bytes erzeugt, und erst dann Base64-kodiert.

Warum das wichtig ist: Die ältere JavaScript-Funktion btoa() verarbeitet nur Latin-1 und wirft InvalidCharacterError bei Zeichen wie é, 中 oder 😀. Unser Wrapper übernimmt die UTF-8-Konvertierung für Sie, sodass Emojis, Chinesisch, Japanisch, Koreanisch, Arabisch, Kyrillisch und jeder Unicode-Codepunkt korrekt kodiert werden.

Falls Sie eine andere Kodierung benötigen:
• UTF-16 LE (Windows-nativ): selten — meist ein Zeichen für Legacy-Interop. Verwenden Sie dennoch new TextEncoder({ fatal: true }).encode(s) und konvertieren Sie vorgelagert.
• ISO-8859-1 / Latin-1: Bilden Sie die Codepunkte 0–255 vor der Kodierung manuell auf Bytes ab.
• GB18030, Shift_JIS, EUC-KR: Nutzen Sie eine Bibliothek wie iconv-lite in Node.js, um zuerst zu transkodieren.

Ein subtiler Fallstrick: Wenn Ihre Quelldaten bereits in einer Nicht-UTF-8-Kodierung vorliegen (z. B. beim Lesen eines Legacy-MySQL-Dumps), dekodieren Sie diese zuerst mit dem korrekten Codec, kodieren Sie dann in UTF-8 um, bevor Sie Base64 anwenden — andernfalls bewahrt das dekodierte Base64 das Mojibake.