Zum Hauptinhalt springen
ToolsByUs

Base64 vs. Hex

Beide sind RFC 4648-Textkodierungen derselben Bytes – der Unterschied liegt in Arithmetik und Habitat. Hex verdoppelt die Größe, bleibt aber nibble-ausgerichtet und ohne Padding und dominiert daher Checksummen, MAC-Adressen und das Debugging. Base64 vergrößert die Daten stattdessen um ein Drittel und dominiert den Massentransport: MIME, JWTs, data URIs und Cookies.

Nur lokal

Base64 vs. Hex erklärt

Die beiden Kodierungen sehen austauschbar aus: Beide machen aus beliebigen Bytes druckbaren Text, beide dekodieren verlustfrei, und beide sind in RFC 4648 nebeneinander definiert. Konkurrenten sind sie weniger als zwei Schreibweisen mit unterschiedlicher Arithmetik – Hexadezimal gibt jedem Byte zwei Zeichen; Base64 packt drei Bytes in vier Zeichen. Alles andere auf dieser Seite, vom Padding bis zum Habitat, folgt aus dieser Arithmetik.

Die Zahlen, präzise: Hexadezimal ist Base16 – sechzehn Zeichen mit je 4 Bit –, also wird aus einem 8-Bit-Byte exakt ein Paar Zeichen, und Nutzlasten wachsen um 100 Prozent. Base64 verwendet vierundsechzig Zeichen mit je 6 Bit, und da das kleinste gemeinsame Vielfache von 8 und 6 die 24 ist, werden drei Bytes zu vier Zeichen: 33 Prozent Overhead, aufgestockt mit =-Padding, wann immer die Eingabe kein Vielfaches von drei Bytes ist.

Diese Seite macht aus dieser Arithmetik Entscheidungen: eine Gegenüberstellung in Tabelle, die Größenrechnung mit durchgerechnetem Beispiel, wo sich jede Kodierung als Konvention etabliert hat, und die Fußfallen – Padding, Alphabet-Varianten, Groß-/Kleinschreibung –, an denen strenge Dekoder scheitern. Die Konverter unten wechseln lokal zwischen beiden, nichts wird hochgeladen.

Um den Größenunterschied an Ihrer eigenen Nutzlast zu sehen: Der Base64-zu-Hex-Konverter kodiert sie lokal neu und zeigt die verdoppelte Zeichenanzahl.

Einen Hex-String für den Transport zu verschlanken funktioniert genauso – der Hex-zu-Base64-Konverter packt je drei Bytes in vier Zeichen, vollständig in Ihrem Browser.

Dieselben Bytes, zwei Alphabete

Beide Kodierungen lösen dasselbe Problem: Bytes sind 8-Bit-Werte, aber Texttransporte – URLs, Header, XML, JSON, E-Mail – arbeiten am liebsten mit druckbarem ASCII. Hex greift auf die sechzehn Zeichen 0-9 und a-f zurück; Base64 auf A-Z, a-z, 0-9, + und /. Keines der beiden verschlüsselt oder komprimiert etwas: Beide sind öffentlich spezifiziert, schlüssellos und sofort umkehrbar, und ein Base64-String ist Transportsicherheit, keine Sicherheit.

AspektBase64Hexadezimal
Alphabet64 Zeichen: A-Z, a-z, 0-9, +, /16 Zeichen: 0-9, a-f
Bits pro Zeichen64
Größenoverhead+33% – 4 Zeichen je 3 Bytes+100% – 2 Zeichen je Byte
Padding= füllt die Ausgabe auf ein Vielfaches von 4 aufKeins – ein Byte sind immer genau 2 Zeichen
VariantenDie URL-sichere Form ersetzt + und / durch - und _Groß-/Kleinschreibung wird per Konvention nicht unterschieden
StammgebieteMIME, JWTs, data: URIs, CookiesChecksummen, UUIDs, MAC-Adressen, Hex-Dumps
StandardRFC 4648, Abschnitte 4 und 5RFC 4648, Abschnitt 8

Die Arithmetik: ein Drittel gegenüber einer Verdopplung

Hex ist nibble-ausgerichtet: Ein Byte zerfällt in zwei 4-Bit-Hälften, von denen jede als ein Zeichen erscheint, daher sind die Längen vorhersehbar – ein Wert aus n Bytes ist immer 2n Zeichen, kein Padding, keine Sonderfälle. Base64 regruppiert Bits in 6-Bit-Blöcke, und 24 Bit ist der erste Punkt, an dem sich Byte-Welt und Base64-Welt treffen, also werden drei Bytes zu vier Zeichen. Ein übrig gebliebenes Byte polstert mit == auf, zwei mit einem einzelnen =.

Ein durchgerechnetes Paar macht das Verhältnis konkret: Die Bytes für Hi sind in Hex 48 69 – vier Zeichen – und in Base64 SGk= – ebenfalls vier Zeichen, Padding inklusive. Bei realen Größen dominiert der Abstand: Ein Megabyte Daten wird als gepolstertes Base64 rund 1.33 MB, als Hex exakt 2 MB. Deshalb haben Massentransporte auf Base64 standardisiert, während kurze Werte bei Hex blieben.

Wo jede Kodierung zuhause ist

Base64 besitzt Masse und Transport. MIME nutzt es für E-Mail-Anhänge, HTTP-Basic-Authentifizierung kodiert Zugangsdaten damit, JWTs verpacken Header, Payload und Signatur in base64url, data: URIs betten Bilder und Schriften direkt in Seiten und Stylesheets ein, und Cookies tragen base64url-Werte, weil sich + und / in URLs und Headern schlecht benehmen. Überall dort, wo Binärdaten eine Nur-Text-Pipe zu Minimalkosten überstehen müssen, ist Base64 die Antwort.

Hex besitzt das Kleine und das vom Menschen Geprüfte. Kryptografische Digests werden per Konvention als Hex ausgegeben – SHA-256-Ausgabe, git-Commit-Bezeichner –, weil feste Breite, kein Padding und byte-ausgerichtete Paare sich mühelos mit dem Auge oder laut vorlesend vergleichen lassen. MAC-Adressen, die Textform von UUIDs und CSS-Farben wie #RRGGBB sind alle Hex, und Hex-Editoren, Speicher-Dumps und Protokoll-Debugger nutzen es, weil jedes Byte eine in sich geschlossene Einheit ist.

Fußfallen und wann sich welches eignet

Base64s Fußfallen liegen alle im Alphabet. Standard- und URL-sichere Variante unterscheiden sich in zwei Zeichen und dürfen nie gemischt werden; Padding fordern strenge Dekoder, die JWT-Konvention entfernt es trotzdem; die Ausgabe unterscheidet Groß- und Kleinschreibung; und MIME bricht Zeilen bei 76 Zeichen um. Hex hat genau eine: die Groß-/Kleinschreibung. Kleinbuchstaben sind die Konvention, Großbuchstaben tauchen in manchen Tools auf, aber das Mischen ist kosmetisch – jeder strenge Dekoder akzeptiert beides.

Also: Base64, wenn Volumen zählt oder ein Protokoll es verlangt – Anhänge, Tokens, eingebettete Binärdaten. Hex für kurze Werte, die Menschen vergleichen, kopieren oder debuggen werden: Digests, Bezeichner, Farben. In echten Systemen kippt die Wahl ständig – ein JWT kommt als base64url an, sein SHA-256-Fingerabdruck ist Hex – und die Konverter unten übernehmen den Wechsel in Ihrem Browser.

Häufig gestellte Fragen

Was ist kompakter, Base64 oder Hex?

Base64, immer und exakt. Hex schreibt 2 Zeichen je Byte; Base64 schreibt 4 Zeichen je 3 Bytes, daher ist die Base64-Ausgabe bei derselben Eingabe zwei Drittel so lang wie die Hex-Ausgabe. Konkret: Ein Megabyte Daten wird als gepolstertes Base64 rund 1.33 MB, als Hex exakt 2 MB.

Ist Base64 Verschlüsselung, oder verbirgt es etwas?

Nein – keine der beiden Kodierungen bietet Geheimhaltung. Beide sind schlüssellose, öffentlich spezifizierte Transformationen, die jeder sofort umkehren kann: Ein Base64-String eines Passworts dekodiert überall zu genau diesem Passwort. Sie lösen Transport, nicht Vertraulichkeit – Binärdaten, die einen Nur-Text-Kanal überstehen. Für Geheimhaltung brauchen Sie Verschlüsselung; danach wird der Chiffretext für den Transport womöglich trotzdem noch base64-kodiert.

Laden die Base64- und Hex-Konverter meine Daten hoch?

Nein. Kodieren, Dekodieren und Konvertieren laufen alle innerhalb Ihres Browser-Tabs; es gibt keinen Upload-Endpunkt, und die Content-Security-Policy der Site erlaubt Netzwerk-Requests nur an sich selbst. Beobachten Sie das DevTools-Netzwerk-Panel während der Konvertierung: Sie werden keine ausgehenden Requests sehen – Payloads, auch versehentlich eingefügte Geheimnisse, verlassen den Tab nie.

Warum werden Hashes und Checksummen in Hex angezeigt?

Eine Konvention, die von der Mechanik gestützt wird. Die Hex-Ausgabe hat feste Breite, braucht kein Padding, und die zwei Zeichen je Byte stehen bündig, sodass Vergleiche und Diffs visuell ausgerichtet sind; ein komplett alphanumerisches Alphabet übersteht Copy-Paste, Logs und CSVs. Jedes Tool von openssl bis git gibt Digests als Hex aus, also ist Hex das, was Menschen zu lesen gelernt haben.

Was ist base64url und wann wird es gebraucht?

Die URL-sichere Variante aus RFC 4648, Abschnitt 5: Minus und Unterstrich ersetzen Plus und Schrägstrich, weil + in der Formular-Kodierung als Leerzeichen gelesen wird und / Pfadsegmente zerlegt. JWTs, Cookies und Query-Parameter nutzen sie, damit Tokens URLs unangetastet überstehen. Dekoder sollten beide Alphabete akzeptieren; strenge lehnen ein gemischtes ab.

Warum endet Base64 manchmal auf = oder ==?

Padding. Die Base64-Ausgabe muss ein Vielfaches von vier Zeichen sein, und wenn die Eingabe kein Vielfaches von drei Bytes ist, polstern ein oder zwei =-Zeichen die letzte Gruppe auf: Ein übrig gebliebenes Byte ergibt ==, zwei ergeben ein einzelnes =. Hex braucht nie Padding, denn zwei Zeichen je Byte teilen sich immer glatt.

Wo kann ich die hier zitierten Standards nachlesen?

  • RFC 4648 — Die Datenkodierungen Base16, Base32 und Base64
ToolsByUs-Team · Wie wir unsere Tools prüfen