Zum Hauptinhalt springen
ToolsByUs

Base64 zu Hex

Dieser Konverter dekodiert Base64 gemäß RFC 4648 und re-kodiert die gleichen Bytes als Kleinbuchstaben-Hexadezimalzahl in Ihrem Browser. Padding wird berücksichtigt, das URL-sichere Alphabet wird akzeptiert, und jeder Byte wird zu genau zwei Hex-Ziffern in der Ausgabereihenfolge abgebildet: ohne Präfixe, ohne Trennzeichen, ohne Upload.

Nur lokal

Base64 zu Hex erklärt

Base64 und hex sind zwei Schreibweisen der gleichen Bytes, und dieser Konverter wandelt zwischen ihnen um: dekodiert das Base64 genau wie RFC 4648 vorschreibt, dann wird jeder dekodierte Byte als zwei Kleinbuchstaben-Hexadezimalziffern ausgegeben. Dazwischen wird nichts neu interpretiert – was Sie erhalten, ist die Byte-Sequenz, die ein Hex-Editor Ihnen zeichen für Zeichen anzeigen würde.

Die interessanten Teile sind die, die Konverter üblicherweise überspringen. Padding: die abschließenden =-Zeichen werden berücksichtigt, und auch Eingabe, deren Padding eine Pipeline entfernt hat, wird akzeptiert. Alphabeten: der Standard-A–Z a–z 0–9 + /-Satz wird dekodiert, und die URL-sichere -_-Variante, die vom gleichen RFC definiert wird, wird vor dem Dekodieren normalisiert. Byte-Reihenfolge: erhalten – ein Byte zu zwei Hex-Ziffern, hohe Nibble zuerst, immer.

Wie jedes Tool auf dieser Seite läuft die Konvertierung in diesem Browser-Tab: Ihr Text verlässt niemals den Rechner, keine Anfrage wird gestellt, und die Content-Security-Policy verbietet der Seite, irgendwohin zu verbinden. Dass das Network-Panel von DevTools während der Konvertierung leer bleibt, ist der Beweis, nicht das Versprechen.

Die Rückkonvertierung – Bytes dargestellt als hex, für einen Header oder ein Token-Feld – wird vom Schwester-Tool Hex zu Base64-Konverter durchgeführt, mit dem gleichen RFC-4648-Alphabet und der gleichen lokalen Verarbeitung.

Wenn die Gruppierungs- und Padding-Regeln willkürlich erscheinen, der Leitfaden über wie Base64 tatsächlich funktioniert baut den gesamten Mechanismus aus ersten Prinzipien in drei kurzen Absätzen auf.

Wie die Konvertierung tatsächlich funktioniert

Die Konvertierung ist zwei gut definierte Stufen mit nichts Verstecktem dazwischen, und jede Stufe hat eine Richtlinie, an die man sie festmachen kann:

  • Normalisieren: Leerzeichen, Zeilenumbrüche (MIME-verpackte Eingabe) und ein führendes ? werden entfernt; die URL-sicheren Zeichen - und _ werden gemäß dem zweiten Alphabet von RFC 4648 auf + und / abgebildet.
  • Dekodieren: die verbleibenden Zeichen werden über das RFC-4648-Alphabet abgebildet – 4 Zeichen zu 3 Bytes – wobei =-Padding am letzten Quant verbraucht wird.
  • Validieren: jedes Zeichen außerhalb des Alphabets ist ein benannter Fehler mit seiner Position; eine Länge von 1 mehr als ein Vielfaches von 4 wird direkt abgelehnt, weil ein einzelner verbleibender Charakter nicht ehrlich einen Byte bilden kann.
  • Ausgeben: jeder Byte wird zu zwei Kleinbuchstaben-Hex-Ziffern, hohe Nibble zuerst, verkettet ohne Trennzeichen und ohne 0x-Präfix.

Padding und Alphabete, präzise

Das Standard-Alphabet von RFC 4648 ist A–Z, a–z, 0–9, + und /, mit =-Padding am letzten Quant, wenn die Byte-Anzahl kein Vielfaches von 3 ist. Das Padding ist bedeutungsvoll – es unterscheidet ein finales Quant von einem Byte von zwei – aber der Dekoder akzeptiert auch ungepaddete Eingabe, wenn die Länge das Quant eindeutig macht (Längen von 2 oder 3 mod 4). Eine Länge von 1 mod 4 ist mit oder ohne Padding ungültig – ein einzelnes Base64-Zeichen kann keinen ganzen Byte erzeugen – und wird stattdessen null-gefüllt abgelehnt.

Die URL-sichere Variante, die vom gleichen RFC definiert ist – Bindestrich und Unterstrich anstelle von Plus und Schrägstrich – wird akzeptiert und normalisiert, was in der Praxis wichtig ist, weil JWTs und URL-Parameter üblicherweise ungepaddet und URL-sicher ausgegeben werden. Die Mischung beider Alphabete in einer Eingabe wird abgelehnt: eine Zeichenfolge, die sowohl + als auch - enthält, hat keine kohärente Lesart.

Wie die Ausgabe aussieht

Das durchgerechnete Beispiel unten ist das exakte Paar, das der Button „Beispiel laden“ erzeugt: das Base64 für „Hello world“ als 22 Kleinbuchstaben-Hex-Ziffern – zwei pro Byte, elf Bytes. Die Ausgabe ist eine durchgehende Zeichenfolge – kein 0x-Präfix, keine Leerzeichen, keine Zeilenumbrüche – weil Hex-Editoren, Dissektoren und Code die reine Form bevorzugen. Die Längenarithmetik: Base64 verbraucht 4 Zeichen pro 3 Bytes, hex verbraucht 2 pro Byte, also ist hex etwa 1,5-mal so lang wie das ungepaddete Base64 – eine Eigenschaft der Kodierungen, nicht Ihrer Daten.

Byte-Reihenfolge, einmalig festgelegt

Endianness spielt keine Rolle, und es ist wichtig zu sagen, warum. Base64 dekodiert zu einer Byte-Sequenz, und eine Sequenz hat eine natürliche Reihenfolge: zuerst dekodierter Byte zuerst. Die Hex-Ausgabe spiegelt diese Reihenfolge exakt wider – Byte n wird zu den Hex-Zeichen an Position 2n und 2n+1 – also ist das Ergebnis derselbe String, den ein Hex-Editor ohne Offsets anzeigen würde. Es gibt kein Wort-Tauschen, keine little-endian-Neuinterpretation, und keine Überraschung, wenn Sie gegen xxd diffen.

Häufig gestellte Fragen

Lädt die Konvertierung von Base64 zu hex meine Daten irgendwo hoch?

Nein. Dekodierung und Re-Kodierung passieren in diesem Browser-Tab, in JavaScript, das mit der Seite geladen wurde. Es gibt keinen Upload-Endpunkt im Seiten-Code, und die Content-Security-Policy der Seite verbietet ausgehende Verbindungen. Überzeugen Sie sich selbst: öffnen Sie DevTools, löschen oder beobachten Sie das Network-Panel, konvertieren Sie und stellen Sie fest, dass keine Anfrage erscheint – das Tool funktioniert mit dem Netzwerkkabel gezogen.

Ist die Hex-Ausgabe in Groß- oder Kleinschreibung?

Kleinbuchstaben, immer – die gleiche Konvention, die xxd und die meisten Hex-Editoren verwenden. Groß- und Kleinschreibung in Hex bezeichnen identische Bytes, und ein Fallfaltungsschritt ist verlustfrei, wenn ein System Großbuchstaben verlangt. Die Ausgabe trägt kein 0x-Präfix, keine Trennzeichen oder Zeilenumbrüche, also kann sie sauber in Code, Dissektoren und Test-Fixtures eingefügt werden.

Warum ist der Hex-String länger als die Base64-Eingabe?

Arithmetik der beiden Kodierungen: Base64 packt 3 Bytes in 4 Zeichen (etwa 33 Prozent Overhead), während hex 2 Zeichen für jeden Byte verwendet (100 Prozent Overhead). Teilen Sie die beiden, und hex ist etwa 1,5-mal so lang wie ungepaddetes Base64 für die gleichen Bytes. Keine der Kodierungen komprimiert irgendetwas – beide sind nur Alphabete über dieselbe Byte-Sequenz.

Benötigt die Eingabe ihr =-Padding?

Nein. Gepaddete Eingabe wird wie gegeben dekodiert, und Padding, das eine Pipeline entfernt hat, wird aus der Länge rekonstruiert – eine Länge von 2 oder 3 mod 4 identifiziert das letzte Quant eindeutig. Die eine Länge, die immer ungültig ist, ist 1 mod 4, mit oder ohne Padding, weil ein einzelnes Base64-Zeichen keinen ganzen Byte erzeugen kann; diese Eingabe wird mit einem klaren Fehler abgelehnt, nie geraten.

Ist Base64-zu-hex-Konvertierung eine Form der Entschlüsselung?

Nein, und die Unterscheidung ist wichtig. Sowohl Base64 als auch hex sind Kodierungen: reversible Schreibweisen der gleichen Bytes ohne Schlüssel irgendwo im Prozess. Jeder kann beide dekodieren, einschließlich dieser Seite, offline. Wenn Ihr Base64 verschlüsselten Chiffretext kodiert, ändert die Konvertierung in hex nur die Darstellung – die Daten sind genau so lesbar oder so geschützt wie zuvor.

Was ist mit URL-sicherem Base64 mit - und _-Zeichen?

Akzeptiert und gehandhabt. RFC 4648 definiert das URL-sichere Alphabet – Bindestrich für Plus, Unterstrich für Schrägstrich – für Kontexte, in denen + und / verfälscht würden, wie JWTs und URL-Pfadsegmente. Der Konverter normalisiert diese Zeichen zum Standard-Alphabet vor dem Dekodieren, also funktioniert ein Token, der direkt aus einem Authorization-Header kopiert wurde, unverändert. Nur eine Mischung beider Alphabete wird abgelehnt.

ToolsByUs-Team · Wie wir unsere Tools prüfen