Base64 / URL / HTML Encoder-Decoder
Base64, URLs, HTML-Entitäten, JWT-Tokens und Hex kodieren und dekodieren — alles im Browser.
Kodierungsformate verstehen
Base64 ist ein Binär-zu-Text-Kodierungsschema, das in RFC 4648 definiert ist und beliebige Binärdaten mithilfe eines 64-Zeichen-Alphabets darstellt: A–Z (26), a–z (26), 0–9 (10) sowie die zwei Sonderzeichen + und / (2) — insgesamt 64 druckbare ASCII-Zeichen. Der Name „Base64" bezieht sich direkt auf diese Alphabetgröße. Da je 3 Eingabebytes exakt 4 Ausgabezeichen entsprechen, erhöht Base64 die Datengröße um etwa 33 %. Dieser vorhersehbare Overhead ist der akzeptierte Preis für die sichere Übertragung von Binärdaten über rein textbasierte Kanäle — E-Mail (RFC 2045 MIME), XML-Attributwerte, JSON-Strings, HTTP-Header und CSS-Data-URIs. RFC 4648 definiert außerdem Base64url, eine URL-sichere Variante, die + durch - und / durch _ ersetzt, um Konflikte mit URL-Syntax zu vermeiden.
URL-Kodierung (Prozent-Kodierung, standardisiert in RFC 3986) ist ein Mechanismus zum Kodieren beliebiger Byte-Sequenzen in einer URI, indem jedes unsichere Byte durch ein Prozentzeichen gefolgt von zwei Hexadezimalziffern ersetzt wird, die den Byte-Wert darstellen. Ein Leerzeichen wird zu %20, ein kaufmännisches Und zu %26 und das deutsche ü (UTF-8-Bytes 0xC3 0xBC) zu %C3%BC. RFC 3986 definiert „unreservierte Zeichen" (A–Z, a–z, 0–9, -, _, ., ~), die keine Prozent-Kodierung benötigen. Jeder Web-Entwickler begegnet der URL-Kodierung bei Query-String-Parametern, HTML-Formularübermittlungen, OAuth-Redirect-URIs und der Konstruktion von Deep-Links. Das korrekte Kodieren jeder URL-Komponente (Schema, Host, Pfad, Query, Fragment) erfordert das Verständnis, welche Zeichen in welcher Komponente sicher sind.
HTML-Entity-Kodierung konvertiert Zeichen mit reservierter Bedeutung in HTML-Markup — vor allem <, >, &, " und ' — in benannte oder numerische Entity-Referenzen (<, >, &, ", '). Dies verhindert, dass Browser nutzerseitige Inhalte als HTML-Markup interpretieren, und macht Entity-Kodierung zu einer der wichtigsten Abwehrmaßnahmen gegen XSS-Schwachstellen (Cross-Site Scripting). Die OWASP XSS Prevention Cheat Sheet empfiehlt, alle nicht vertrauenswürdigen Daten zu kodieren, bevor sie in HTML-Output eingefügt werden. Unser HTML-Encoder behandelt alle fünf reservierten Zeichen und gängige Sonderzeichen und erzeugt sicheren Output für die Einbettung in HTML-Dokumente.
JWT (JSON Web Tokens, RFC 7519) ist ein kompaktes, URL-sicheres Format zur Darstellung von Claims zwischen zwei Parteien. Ein JWT besteht aus drei Base64url-kodierten Abschnitten, getrennt durch Punkte: dem Header (der den Algorithmus angibt, z. B. HS256 oder RS256), dem Payload (der die Claims enthält, z. B. sub, iat, exp, roles) und der Signatur. Da Header und Payload nur Base64url-kodiert — nicht verschlüsselt — sind, können ihre Inhalte von jedem gelesen werden, der das Token besitzt. Die Signatur gewährleistet die Integrität: Sie beweist, dass das Token von der Partei ausgestellt wurde, die den geheimen Schlüssel besitzt, und nicht manipuliert wurde. JWTs sind das dominierende Authentifizierungstoken-Format für OAuth 2.0, OpenID Connect und API-Autorisierung in modernen Web-Anwendungen.
Hexadezimale (Basis-16) Kodierung stellt jedes Byte als genau zwei Hexadezimalziffern (0–9, a–f) dar und erzeugt eine Ausgabe, die doppelt so groß wie die Eingabe ist. Hexadezimal ist die Standarddarstellung für kryptographische Ausgaben: SHA-256-Hashes werden als 64 Hex-Zeichen dargestellt, MD5 als 32, TLS-Zertifikat-Fingerabdrücke als Hex-Strings. Es wird beim Debuggen (Speicher-Dumps, Netzwerkpaketinspektion), bei Farbcodes in CSS (#RRGGBB), UUID-Darstellungen und der Low-Level-Dateninspektion verwendet. Unser Hex-Encoder konvertiert beliebigen Text (als UTF-8 kodiert) in seine hexadezimale Darstellung und zurück.
So verwenden Sie dieses Tool
- Tab auswählen — Wählen Sie zwischen Base64, URL, HTML, JWT oder Hex-Kodierung. Jeder Tab ist für sein spezifisches Kodierungsformat optimiert, mit passenden Eingabe-Platzhaltern und kontextbezogenen Hinweisen.
- Richtung wählen — Schalten Sie zwischen Kodieren und Dekodieren um (außer für JWT, das nur zum Dekodieren gedacht ist — Header und Payload eines JWT sind immer Base64url-kodiert, nicht verschlüsselt).
- Eingabe eingeben — Fügen Sie Ihre Daten in das Eingabefeld ein oder geben Sie sie ein. Bei Base64 und Hex verarbeitet das Tool sowohl ASCII als auch vollständigen Unicode-Input (kodiert ihn als UTF-8-Bytes vor der Transformation). Bei URL-Kodierung fügen Sie die Komponente ein, die Sie kodieren möchten — nicht die gesamte URL.
- Verarbeiten — Klicken Sie auf die Schaltfläche oder drücken Sie Strg+Enter, um zu kodieren oder zu dekodieren. Das Ergebnis erscheint sofort im Ausgabefeld.
- Ergebnis kopieren — Klicken Sie auf „Kopieren", um die Ausgabe in Ihre Zwischenablage zu kopieren. Der Kopier-Button bestätigt den Erfolg mit einem „Kopiert!"-Hinweis.
Die gesamte Verarbeitung erfolgt lokal in Ihrem Browser mithilfe nativer JavaScript-APIs (btoa/atob, encodeURIComponent/decodeURIComponent, TextEncoder/TextDecoder). Es werden keine Daten an einen Server übertragen. Dies macht das Tool sicher für die Kodierung sensibler Zugangsdaten, privater JWT-Payloads und vertraulicher Dokumentenanhänge.
Wie es funktioniert
Base64-Kodierung funktioniert, indem Eingabebytes in 3-Byte-Blöcke gruppiert werden. Jeder 3-Byte-Block (24 Bits) wird in vier 6-Bit-Gruppen aufgeteilt. Jeder 6-Bit-Wert (0–63) wird einem Zeichen im Base64-Alphabet zugeordnet. Ist die Eingabelänge nicht durch 3 teilbar, werden ein oder zwei Auffüllzeichen = angefügt, damit die Ausgabelänge ein Vielfaches von 4 ist. Für Unicode-Text kodiert unser Tool den String zunächst mit der TextEncoder-API als UTF-8-Bytes und wendet dann Base64 an — der korrekte Ansatz für Nicht-ASCII-Zeichen wie deutsche Umlaute (ä, ö, ü) oder andere Zeichen außerhalb des ASCII-Bereichs.
URL-Kodierung verwendet JavaScripts natives encodeURIComponent() für die Kodierung und decodeURIComponent() für die Dekodierung. Diese Funktionen halten sich an RFC 3986 und lassen unreservierte Zeichen (A–Z, a–z, 0–9, -, _, ., ~) unkodiert, während alles andere prozent-kodiert wird — einschließlich Zeichen mit besonderer Bedeutung in URLs (/, ?, #, =, &). Bei Mehrbyte-UTF-8-Zeichen wird jedes Byte einzeln prozent-kodiert — zum Beispiel wird ü (U+00FC) zu %C3%BC in einer URL.
JWT-Dekodierung trennt das Token an den beiden Punkt-Trennzeichen in Header-, Payload- und Signatur-Segmente. Jedes Segment wird Base64url-dekodiert: Die - und _ Zeichen werden durch + und / ersetzt (Rückgängigmachen der URL-sicheren Substitution), fehlendes Padding wird ergänzt und das Ergebnis mit atob() dekodiert. Die dekodierten Bytes werden als UTF-8-JSON geparst und als formatierte, eingerückte JSON-Objekte dargestellt. Das Signatur-Segment wird als rohes Base64url angezeigt — ohne den geheimen Schlüssel ist keine Verifikation möglich, und docutools.pro fordert keine Schlüssel an und speichert keine.
Anwendungsfälle
XRechnung- und ZUGFeRD-Anhänge einbetten
Der XRechnung-Standard erlaubt das Einbetten von Binäranlagen (begleitende PDFs, Spezifikationen, Lieferscheine) über das Element AdditionalDocumentReference. Der Binärinhalt muss als Standard-Base64 (RFC 4648) für das Element EmbeddedDocumentBinaryObject kodiert werden. Unser Encoder erzeugt genau dieses Format. ZUGFeRD-Einbettung funktioniert identisch im CII-XML-Anhang. Verwenden Sie unser Tool, um kleine PDFs oder Bilder zu kodieren, bevor Sie ein Rechnungs-XML manuell bearbeiten.
API-Authentifizierung debuggen
HTTP Basic Authentication kodiert Zugangsdaten als Base64(Benutzername:Passwort) im Authorization-Header. OAuth 2.0-Client-Credentials werden teils ähnlich Base64-kodiert. JWTs tragen Claims in einem lesbaren Payload. Unser Tool deckt alle drei ab: Basic-Auth-Kodierung, JWT-Payload-Inspektion und OAuth 2.0-Token-Debugging. Wenn eine API 401 Unauthorized zurückgibt, ist das Dekodieren des gesendeten Tokens der erste Debugging-Schritt.
Web-Sicherheit und XSS-Prävention
Beim Aufbau von Web-Anwendungen, die nutzerseitige Inhalte darstellen, muss jeder String vor dem Einfügen in die Seite HTML-entity-kodiert werden. Unser HTML-Encoder wandelt die fünf gefährlichen Zeichen (<, >, &, ", ') in ihre sicheren Entity-Formen um. Verwenden Sie dies, um zu prüfen, ob Ihr Backend die richtige Ausgabe erzeugt, oder um einen Test-String manuell zu kodieren und die Template-Engine-Konfiguration zu verifizieren.
Kryptographische Ausgaben inspizieren
SHA-256-Hashes, HMAC-Signaturen, TLS-Zertifikat-Fingerabdrücke und bcrypt-Hashes werden alle als Hexadezimal-Strings dargestellt. Unser Hex-Encoder konvertiert zwischen Rohtext und Hex und hilft beim Verifizieren von Hash-Ausgaben, Inspizieren von Zertifikat-Fingerabdrücken oder dem Verstehen der Byte-Level-Repräsentation kryptographischer Schlüssel und Nonces.
Beispiel: Base64-kodierter Anhang
So wird ein kurzer Text Base64-kodiert (RFC 4648) und als Anhang in eine XRechnung eingebettet. Jeder Base64-Decoder weltweit — auch unser Tool — liefert exakt denselben Originaltext aus diesem kodierten String zurück.
Eingabe (Klartext):
Rechnung RE-2025-001 vom 15.01.2025
Base64-Ausgabe:
UmVjaG51bmcgUkUtMjAyNS0wMDEgdm9tIDE1LjAxLjIwMjU=
In XRechnung XML:
<cac:AdditionalDocumentReference>
<cbc:ID>Anhang-1</cbc:ID>
<cac:Attachment>
<cbc:EmbeddedDocumentBinaryObject mimeCode="text/plain"
filename="rechnung.txt">
UmVjaG51bmcgUkUtMjAyNS0wMDEgdm9tIDE1LjAxLjIwMjU=
</cbc:EmbeddedDocumentBinaryObject>
</cac:Attachment>
</cac:AdditionalDocumentReference>Das abschließende = ist Padding — es zeigt an, dass die Eingabelänge kein Vielfaches von 3 Bytes war und ein Auffüllzeichen angefügt wurde, damit die Ausgabelänge ein Vielfaches von 4 ist.
Tipps & Einschränkungen
Tipps
- Verwenden Sie Strg+Enter als Tastenkürzel für schnelles Kodieren oder Dekodieren ohne Mausbewegung.
- Beim Kodieren von Unicode-Text (deutsche Umlaute ä/ö/ü, Akzentzeichen, CJK-Schriften) verwendet unser Tool UTF-8-Kodierung — den universellen Standard für Text-APIs. So dekodiert Ihr Base64-String auf jeder Plattform korrekt.
- JWT-Dekodierung zeigt Header und Payload, ohne die Signatur zu prüfen. Vertrauen Sie einem JWT in Produktionscode niemals ohne serverseitige Signaturverifizierung mit dem öffentlichen Schlüssel des Ausstellers oder dem gemeinsamen Geheimnis.
- Base64url (verwendet in JWTs und einigen OAuth-Flows) ersetzt + durch - und / durch _ für URL-sichere Token. Unser JWT-Decoder verarbeitet Base64url automatisch; der Base64-Tab erzeugt Standard-Base64 (mit + und /).
Einschränkungen
- Base64 ist Kodierung, keine Verschlüsselung. Jeder, der einen Base64-String besitzt, kann ihn sofort ohne Schlüssel dekodieren. Für Vertraulichkeit verschlüsseln Sie die Daten zuerst mit AES-256 oder RSA und kodieren dann den Chiffretext bei Bedarf mit Base64 für den Transport.
- JWT-Signaturverifizierung erfordert den geheimen Schlüssel (für HMAC-Algorithmen) oder den öffentlichen Schlüssel des Ausstellers (für RSA/ECDSA). Unser Tool zeigt den dekodierten Payload, kann aber keine Signaturen verifizieren oder fälschen — dies ist beabsichtigt.
- URL-Kodierung kodiert einen einzelnen Komponentenwert, keine vollständige URL. Wenn Sie eine ganze URL (https://example.com/pfad?key=wert) in den URL-Encoder einfügen, werden Schrägstriche, Doppelpunkte und Fragezeichen prozent-kodiert und zerstören die URL-Struktur. Kodieren Sie jeden Query-Parameter-Wert einzeln.
- Sehr große Eingaben (Multi-MB-Dateien) können den Browser verlangsamen, da die gesamte Verarbeitung vollständig client-seitig erfolgt. Für die Base64-Kodierung großer Binärdateien empfehlen sich Kommandozeilen-Tools (base64 unter Linux/macOS, certutil -encode unter Windows).
Häufig gestellte Fragen
Ist Base64-Kodierung dasselbe wie Verschlüsselung?
Nein — dies ist eines der häufigsten Missverständnisse in der Software-Sicherheit. Base64 ist ein Kodierungsschema, keine Verschlüsselung. Es gibt keinen Schlüssel, kein Geheimnis und keinen rechnerischen Aufwand. Jeder, der einen Base64-String empfängt, kann ihn sofort mit jeder Base64-Bibliothek oder jedem Online-Tool dekodieren. Es dient der sicheren Übertragung von Binärdaten über Textkanäle, nicht der Vertraulichkeit. Wenn Sie Daten schützen müssen, verwenden Sie authentifizierte Verschlüsselung (AES-256-GCM, ChaCha20-Poly1305).
Warum ist meine Base64-Ausgabe etwa 33 % größer als die Eingabe?
Base64 ordnet je 3 Eingabebytes exakt 4 Ausgabezeichen zu — ein Verhältnis von 4/3 ≈ 1,333. Eine 1-MB-Binärdatei erzeugt damit etwa 1,37 MB Base64-Text. Dieser Overhead ist der unvermeidliche Preis für die Darstellung von 8-Bit-Bytes mit nur 6 Informationsbits pro Zeichen (log₂(64) = 6). Deshalb sind Data-URIs für Bilder nicht für große Dateien geeignet und Base64 nie zur Datenkomprimierung — es vergrößert die Daten immer.
Kann ich ein JWT ohne den geheimen Schlüssel dekodieren?
Ja — Header und Payload eines JWT sind nur Base64url-kodiert, nicht verschlüsselt. Jeder, der den Token-String besitzt, kann die Claims (sub, E-Mail, Rollen, exp, iat usw.) ohne Kenntnis eines Schlüssels lesen und dekodieren. Die Signatur stellt die Integrität sicher: Sie beweist, dass das Token von der richtigen Partei ausgestellt und nicht manipuliert wurde. Das bedeutet: Legen Sie niemals sensible Daten (Passwörter, PII, die Sie verbergen möchten) in einen JWT-Payload, ohne das Token zusätzlich zu verschlüsseln (JWE, RFC 7516).
Werden meine Daten bei der Nutzung dieses Tools an einen Server gesendet?
Nein. Alle Kodierungs- und Dekodierungsvorgänge laufen vollständig in Ihrem Browser mithilfe nativer JavaScript-APIs (btoa/atob für Base64, encodeURIComponent/decodeURIComponent für URLs, TextEncoder/TextDecoder für Unicode). Ihre Daten verlassen Ihr Gerät niemals. Das ist besonders wichtig für JWT-Tokens, die sensible Nutzer-Claims enthalten, und für Passwörter, die in HTTP-Basic-Auth-Headern kodiert sind.
Was ist der Unterschied zwischen Base64 und Base64url?
Standard-Base64 (RFC 4648 §4) verwendet + und / als 62. und 63. Zeichen und füllt die Ausgabe mit = auf ein Vielfaches von 4 auf. Base64url (RFC 4648 §5) ersetzt + durch - und / durch _, damit der kodierte String in URLs und HTTP-Headern ohne Prozent-Kodierung erscheinen kann. JWT-Token verwenden Base64url. Bei Zweifeln, welche Variante zu verwenden ist, prüfen Sie, ob die Zieldokumentation RFC 4648 §4 (Standard) oder §5 (URL-sicher) nennt.
Wie kodiere ich ein Bild als Base64-Data-URL für CSS oder HTML?
Lesen Sie die Bilddatei als Binärbytes, kodieren Sie die Bytes mit RFC 4648 Standard-Base64 und konstruieren Sie dann die Data-URL mit dem MIME-Type-Präfix: data:[mimeType];base64,<kodiert>. Für ein PNG: data:image/png;base64,iVBORw0KGgo.... Dieser String kann direkt als src eines <img>-Tags oder als url()-Wert in CSS verwendet werden. Wichtig: Data-URLs erhöhen die HTML/CSS-Dateigröße um ~33 % und können vom Browser nicht separat gecacht werden — verwenden Sie sie nur für kleine Grafiken (Icons, kleine Logos).
Was bedeutet das =-Padding am Ende von Base64?
Die Base64-Ausgabe muss ein Vielfaches von 4 Zeichen lang sein. Ist die Eingabelänge nicht durch 3 teilbar, wird Padding angefügt: Ein = bedeutet, dass 1 Byte Padding hinzugefügt wurde (2 Eingabebytes in der letzten Gruppe); == bedeutet 2 Bytes Padding (1 Eingabebyte in der letzten Gruppe). Kein Padding bedeutet, dass die Eingabe exakt durch 3 teilbar war. Einige Systeme (insbesondere JWT Base64url) lassen das Padding weg. Wenn Sie einen „Incorrect padding"-Dekodierungsfehler sehen, fügen Sie ein oder zwei = am Ende hinzu.
Wie bette ich eine PDF-Datei als Base64-Anhang in XRechnung-XML ein?
Lesen Sie die PDF-Datei als Binärbytes (z. B. mit FileReader.readAsDataURL() in JavaScript oder file.read() in Python gefolgt von base64.b64encode()). Kodieren Sie die Bytes mit Standard-Base64 (RFC 4648 §4). Platzieren Sie den kodierten String im Element cbc:EmbeddedDocumentBinaryObject unter AdditionalDocumentReference mit den Attributen mimeCode="application/pdf" und filename. Wichtig: XRechnung validiert, dass der mimeCode einer der erlaubten Typen ist (application/pdf, image/png, image/jpeg, text/csv, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet). Übermäßig große Anhänge (>5 MB) werden von manchen Portalimplementierungen abgelehnt.
Welche Zeichenkodierung sollte ich vor der Base64-Kodierung von Text verwenden?
Kodieren Sie Text immer als UTF-8-Bytes, bevor Sie Base64 anwenden. UTF-8 ist die universell interoperable Kodierung für Textdaten in APIs, XML, JSON und E-Mail. Die Verwendung von UTF-16 oder Latin-1 erzeugt gültiges Base64, aber der Empfänger muss wissen, welche Kodierung verwendet wurde. Unser Tool verwendet die TextEncoder-API des Browsers, die immer UTF-8 erzeugt. Das verarbeitet deutsche Umlaute (ä, ö, ü, ß), französische Akzente, Griechisch, Arabisch, CJK-Zeichen und jeden anderen Unicode-Text korrekt.
Wie dekodiere ich ein JWT, um Authentifizierungsprobleme zu debuggen?
Fügen Sie das vollständige JWT (alle drei durch Punkte getrennten Segmente) in den JWT-Tab unseres Tools ein und klicken Sie auf Dekodieren. Der Header zeigt den Algorithmus (alg: HS256, RS256, ES256 usw.) und den Token-Typ. Der Payload zeigt die Claims: sub (Subject/Nutzer-ID), iat (Ausstellungszeitpunkt als Unix-Timestamp), exp (Ablaufzeitpunkt — prüfen Sie diesen zuerst bei 401-Fehlern), aud (Audience), iss (Aussteller) sowie alle benutzerdefinierten Claims Ihres Identity Providers. Der exp-Claim ist ein Unix-Timestamp — verwenden Sie unseren Timestamp-Konverter, um ihn in ein menschenlesbares Datum umzuwandeln und zu prüfen, ob der Token abgelaufen ist.