# Base64-Encoder

URL: https://www.toolflux.app/base64-encoder/
Stand: 2026-06-05

Base64 Schritt für Schritt: 3-Byte-Gruppen als Chips, 4-Zeichen-Blöcke daneben, Padding und URL-safe-Variante erklärt. Encode und Decode in einem Tool.

Wenn du in einem Konfig-File `cGFzc3dvcmQ6IHN1cGVyc2VjcmV0` siehst oder ein API-Token mit `eyJ` startet, schaust du auf Base64. Es ist keine Verschlüsselung und kein Protokoll, sondern eine reine Übersetzungsschicht: beliebige Bytes werden in 64 sichere ASCII-Zeichen gepackt, damit sie durch Text-Kanäle wie URLs, JSON-Strings oder E-Mail-Header passen. Der Encoder unten zeigt die UTF-8-Bytes deiner Eingabe in 3-Byte-Gruppen, daneben den passenden 4-Zeichen-Block der Ausgabe.

## Was ist Base64 und warum sieht es so aus?

Base64 verpackt drei Bytes (24 Bits) in vier Zeichen aus einem 64er-Alphabet (`A-Z`, `a-z`, `0-9`, `+`, `/`). Dadurch wächst die Größe um etwa 33 Prozent - der Preis dafür, dass das Ergebnis nur aus harmlosen ASCII-Zeichen besteht und Binärdaten durch Systeme transportieren kann, die sonst nur Text durchlassen.

Die Ergebnisansicht oben zerlegt deine Eingabe in vier Kategorien: ASCII-Bytes grau, UTF-8-Lead-Bytes orange, UTF-8-Continuation-Bytes gelb, Padding `=` violett. Jede 3-Byte-Gruppe links bekommt einen 4-Zeichen-Block rechts. Bei `hello` (5 Bytes) entstehen zwei Blöcke - der zweite ist mit einem `=` aufgefüllt. Bei `München` siehst du, wie `Mü` als drei Bytes (`4D C3 BC`) zum Block `TcO8` wird.

Direkt unter den Chips läuft eine Bit-Leiste mit: drei 8-Bit-Bytes auf der Eingabe-Seite, vier 6-Bit-Sextets auf der Ausgabe-Seite. Beide Seiten tragen exakt 24 Bit, nur anders zerschnitten. Markierst du einen Block, springt die Leiste auf diesen Quanten - so siehst du Byte für Byte, wie aus `4D C3 BC` (also `01001101 11000011 10111100`) die Sextets `19 28 14 60` werden, die im Standard-Alphabet `T c O 8` heißen.

## Wann triffst du auf Base64?

Base64 ist überall dort, wo Bytes durch Textkanäle müssen. Nicht nur Entwickler lesen das. Power-User, Sysadmins und Studierende stoßen genauso darauf, meist ohne zu wissen, dass es eine Übersetzung ist und kein Geheimcode.

- **Kubernetes-Secrets** speichern `data`-Werte in der YAML-Datei Base64-kodiert (`echo -n "passwort" | base64` ergibt `cGFzc3dvcmQ=`). `stringData` ist die Klartext-Alternative.
- **Data-URIs** in HTML wie `data:image/png;base64,iVBORw0KG...` betten Bilder direkt in das Markup ein.
- **JWT-Tokens** bestehen aus drei Base64-url-safe-Teilen: Header, Payload, Signatur. [→ JWT-Header dekodieren](/base64-encoder/?i=eyJhbGciOiJIUzI1NiJ9&m=decode&v=url_safe)
- **E-Mail-Anhänge** wandern seit den 90ern als Base64 durch SMTP, weil das Protokoll nur 7-Bit-ASCII garantiert.
- **Browser-APIs** wie `FileReader.readAsDataURL` liefern Base64. JWK-Felder aus `crypto.subtle.exportKey("jwk", ...)` nutzen Base64url.

Brauchst du die Bytes als Hex-Liste statt als Base64 - etwa um sie gegen `xxd`, einen Hex-Viewer oder die Ausgabe von `openssl` zu halten - liefert die Aktion "Hex kopieren" die Sequenz fertig zum Einfügen.

## Standard oder URL-safe - welche Variante passt?

Der Variant-Schalter oben entscheidet zwischen den zwei Alphabeten aus RFC 4648. Standard (§4) nutzt `+` und `/`. Beide sind in URLs Sonderzeichen und werden bei `?q=cGFzc/+=` zu `cGFzc%2F%2B%3D` - lesbar wird das nicht. URL-safe (§5) ersetzt `+` durch `-`, `/` durch `_` und lässt das Padding-`=` meist weg, sodass die Zeichenkette ohne weiteres in einer URL, in einem Dateinamen oder in einem Cookie-Wert stehen darf.

| Szenario | Richtig | Was sonst schiefgeht |
|---|---|---|
| Bytes in YAML, JSON, Header | Standard | Das ist der Default fast überall |
| Token in URL-Pfad oder -Query | URL-safe | `+` und `/` müssen sonst URL-kodiert werden |
| Dateinamen aus einer Hash-Eingabe | URL-safe | `/` würde einen neuen Pfad-Teil bilden |
| JWT (Header, Payload, Signatur) | URL-safe | Standard funktioniert nicht im Token-Format |

Im Zweifel Standard. Wechsle erst dann auf URL-safe, wenn du den Base64-String in eine URL oder einen Dateinamen schreibst.

## Was bedeutet das `=` am Ende?

Padding-`=` füllt den letzten Block auf vier Zeichen auf. Base64 nimmt drei Bytes auf einmal. Hat dein Input ein Vielfaches von drei Bytes, gibt es kein `=`. Bleibt am Ende ein Byte übrig, kommen zwei `=`. Bleiben zwei Bytes übrig, kommt ein `=`.

1. **`hello` (5 Bytes)** → ein voller 3-Byte-Block plus 2 Bytes übrig → `aGVsbG8=` ([→ Beispiel laden](/base64-encoder/?i=hello)).
2. **`hi` (2 Bytes)** → 2 Bytes übrig → `aGk=`.
3. **`Foo` (3 Bytes)** → exakt aufgegangen → `Rm9v`, kein Padding.
4. **`a` (1 Byte)** → ein Byte übrig → `YQ==`.

Das Padding ist nicht nur Kosmetik. Decoder können daraus die exakte Byte-Anzahl ableiten, ohne den Rest zu interpretieren. Die URL-safe-Variante lässt das Padding meist weg, weil die Länge auch implizit ableitbar ist - der Decoder oben akzeptiert beides.

## Warum ist `btoa()` bei Umlauten tückisch?

`btoa(string)` ist eine Browser-API aus den 90ern. Sie erwartet einen Byte-String, also Zeichen mit Codewerten von `0x00` bis `0xFF`. Ein `ü` (U+00FC) liegt zwar in diesem Bereich, deshalb wirft `btoa("München")` nicht. Das Ergebnis ist aber `TfxuY2hlbg==`, weil `ü` als einzelnes Byte `0xFC` behandelt wird. Die UTF-8-Form, die APIs normalerweise erwarten, ist `TcO8bmNoZW4=`.

Sobald ein Emoji oder ein chinesisches Zeichen kommt, wirft `btoa` `InvalidCharacterError`, weil diese Zeichen nicht in ein einzelnes Byte passen. Der Encoder oben löst beides, indem er über `TextEncoder` geht: erst Text in UTF-8-Bytes zerlegen, dann `String.fromCharCode(...bytes)` aufrufen, dann `btoa`. Dieselbe Logik gilt fürs Dekodieren: `atob` liefert eine Byte-Sequenz, die `TextDecoder` als UTF-8-Text zurück übersetzt. Bei `München` siehst du in der Ergebnisansicht oben den Sprung von 7 Zeichen auf 8 Bytes - das `ü` belegt zwei davon.

## Häufige Fragen

### Was ist Base64 und warum gibt es das?

Base64 ist eine Kodierung, die beliebige Bytes in nur 64 sichere ASCII-Zeichen verpackt (`A-Z`, `a-z`, `0-9`, `+`, `/`). Ursprung sind E-Mails, die jahrzehntelang nur 7-Bit-ASCII transportieren konnten. Heute taucht Base64 in Data-URIs, JWT-Tokens, Kubernetes-Secrets und überall dort auf, wo Binärdaten durch einen Text-Kanal müssen.

### Was bedeutet das `=` am Ende einer Base64-Zeichenkette?

Das `=` ist Padding. Base64 verpackt drei Bytes in vier Zeichen. Wenn die Eingabe nicht durch drei teilbar ist, wird der letzte Block mit `=` aufgefüllt. Ein `=` heißt zwei Daten-Bytes im letzten Block, zwei `=` heißen ein Daten-Byte. Die URL-safe-Variante lässt das Padding meist weg.

### Warum produziert `btoa()` bei Umlauten Müll?

`btoa(string)` erwartet einen Byte-String. Umlaute wie `ü` werden dann als Latin-1-Byte behandelt, Emoji und viele andere Zeichen werfen einen Fehler. Der Tool-Code geht über `TextEncoder` und produziert die UTF-8-Base64-Form, die Server und APIs erwarten. Auch der [URL-Encoder](/url-encoder/) benutzt UTF-8 als Zwischenschritt.

### Ist Base64 eine Verschlüsselung?

Nein. Base64 ist eine Kodierung, keine Verschlüsselung. Jeder mit dem String und dem Decoder erhält den Klartext zurück. Wenn du etwas geheim halten musst, brauchst du Verschlüsselung (AES, RSA, libsodium).

### Wann brauche ich Base64 in einer URL?

Wann immer Bytes durch eine URL müssen, ohne dass sie zerstört werden. JWT-Tokens, OAuth-State-Parameter, Webhook-Signaturen, manchmal Bild-Hashes in Pfaden. Wechsle dann auf die URL-safe-Variante - sonst landest du am Ende mit doppelter Kodierung. Mehr zur Mechanik im [URL-Encoder](/url-encoder/).

### FAQ

**Was ist Base64 und warum gibt es das?**

Base64 ist eine Kodierung, die beliebige Bytes in nur 64 sichere ASCII-Zeichen verpackt (`A-Z`, `a-z`, `0-9`, `+`, `/`). Ursprung sind E-Mails, die jahrzehntelang nur 7-Bit-ASCII transportieren konnten. Heute taucht Base64 in Data-URIs, JWT-Tokens, Kubernetes-Secrets und überall dort auf, wo Binärdaten durch einen Text-Kanal müssen.

**Was bedeutet das `=` am Ende einer Base64-Zeichenkette?**

Das `=` ist Padding. Base64 verpackt drei Bytes in vier Zeichen. Wenn die Eingabe nicht durch drei teilbar ist, wird der letzte Block mit `=` aufgefüllt. Ein `=` heißt zwei Daten-Bytes im letzten Block, zwei `=` heißen ein Daten-Byte. Die URL-safe-Variante lässt das Padding meist weg.

**Warum produziert `btoa()` bei Umlauten Müll oder einen Fehler?**

`btoa(string)` erwartet einen Byte-String. `btoa("München")` wirft nicht, kodiert das `ü` aber als Latin-1-Byte `0xFC` und liefert nicht die UTF-8-Base64-Form. Bei Emoji oder chinesischen Zeichen wirft `btoa` `InvalidCharacterError`. Der Tool-Code geht über `TextEncoder` → Bytes → `btoa(String.fromCharCode(...bytes))` und produziert das, was Server und APIs für UTF-8-Text erwarten.

**Was ist der Unterschied zwischen Standard- und URL-safe-Base64?**

Standard (RFC 4648 §4) nutzt `+` und `/`. Die landen in URLs als Sonderzeichen und müssen dann zusätzlich URL-kodiert werden. URL-safe (§5) ersetzt `+` durch `-` und `/` durch `_`. Die Variante darf direkt in URLs, Dateinamen und Cookie-Werte. Padding-`=` wird in der URL-safe-Variante häufig weggelassen.

**Ist Base64 eine Verschlüsselung?**

Nein. Base64 ist eine Kodierung, keine Verschlüsselung. Jeder mit dem String und dem Decoder erhält den Klartext zurück. Wenn du etwas geheim halten musst, brauchst du Verschlüsselung (AES, RSA, libsodium). Base64 ist dafür da, Bytes durch Text-Kanäle zu schicken.

**Wie viele Bytes werden aus einem Base64-String?**

Faustregel: aus 4 Base64-Zeichen werden bis zu 3 Daten-Bytes. Ein Base64-String mit 100 Zeichen kodiert also höchstens 75 Bytes. Genauer: Kodieren von n Bytes ergibt 4 × ⌈n/3⌉ Zeichen. Dekodieren ergibt 3 × Block-Anzahl minus Padding-Zeichen.