Zum Hauptinhalt springen
ToolsByUs

Hex zu Base64

Dieser Konverter wandelt eine Hexadezimalzeichenkette in Standard-Base64 in Ihrem Browser um. Die Eingabe ist case-insensitiv, 0x-Präfixe und überflüssige Leerzeichen werden entfernt, und die Ausgabe folgt RFC 4648 mit Padding. Eingaben mit ungerader Länge werden zurückgewiesen: eine fehlende Nibble wird nie erraten. Es wird nichts hochgeladen.

Nur lokal

Hex zu Base64 erklärt

Hex ist die Schreibweise von Bytes für Programmierer; Base64 ist die für die Datenübertragung. Dieser Konverter liest eine Hexadezimalzeichenkette paarweise und re-kodiert dieselben Bytes im RFC-4648-Standardalphabet, inklusive Padding – die exakte Zeichenkette, die ein korrekter Encoder für die zugrundeliegenden Daten erzeugen würde, bereit für einen Header, eine Konfigurationsdatei oder ein Tokenfeld.

Reale Hex-Daten sind unordentlich, und der Konverter gibt ihnen nach: Groß- und Kleinbuchstaben sind gleichwertig, 0x-Präfixe werden überall entfernt, und überflüssige Leerzeichen – Spaltendumps, gepaarte Zeichen mit Abstand, Zeilenumbrüche – werden vor der Verarbeitung bereinigt. Was er nicht tut, ist raten. Eine ungerade Anzahl von Hex-Zeichen bedeutet, dass eine Nibble irgendwo fehlt, und der Konverter lehnt ab, anstatt eine Position zu erfinden.

Die Umwandlung erfolgt vollständig lokal, wie überall auf dieser Seite: Ihre Zeichenkette wird in diesem Browser-Tab analysiert und kodiert, es wird keine Anfrage gesendet, und die Content-Security-Policy der Seite verbietet ausgehende Verbindungen. Der leere Network-Panel während der Umwandlung ist der Beweis, in Sekunden überprüfbar.

Die Überprüfung des Ergebnisses von Hand ist in die entgegengesetzte Richtung einfach: füttern Sie das Ergebnis an den Base64 zu Hex-Konverter und Sie sollten Ihre ursprüngliche Hex-Zeichenkette zurückbekommen, Byte für Byte.

Die Wahl zwischen den beiden Kodierungen ist Thema der Base64 vs. Hex-Vergleich die Größe, Lesbarkeit und Protokolltauglichkeit vergleicht, ohne den Stammes-Mythos.

Wie die Umwandlung tatsächlich funktioniert

Die Gruppierungsregel von Base64 erledigt die eigentliche Arbeit, und es lohnt sich, sie einmal zu sehen, weil sie sowohl die Länge als auch das Padding der Ausgabe dieses Tools erklärt:

  • Bereinigen: 0x- und 0X-Präfixe werden entfernt, alle Leerzeichen werden gelöscht, und die verbleibenden Zeichen müssen 0–9, a–f oder A–F sein; alles andere ist ein benannter Fehler mit seiner Position.
  • Paar: Jede zwei Hex-Zeichen werden zu einem Byte – 48 ist das Byte 0x48, der Buchstabe H.
  • Gruppe: Bytes werden zu je drei genommen; die 24 Bits jedes Tripels werden in vier 6-Bit-Werte aufgeteilt, und jeder Wert wird auf ein Zeichen des RFC-4648-Alphabets A–Z a–z 0–9 + / abgebildet.
  • Padding: Eine letzte Gruppe von 1 oder 2 Bytes wird mit =-Zeichen vervollständigt, sodass die Ausgangslänge immer ein Vielfaches von 4 ist.

Eingabe wird bereinigt, nicht bewertet

Hex in der Wildnis kommt verziert an. Hash-Digests kommen von einigen Bibliotheken mit 0x-Präfix; Paketdumps kommen als Spalten von gepaarten Zeichen mit Abstand; Dokumentation schreibt 48 65 6C mit Großbuchstaben, während ein Log 48656l in Kleinbuchstaben gedruckt hat. All das sind dieselben Bytes, also behandelt der Konverter es gleich: Präfixe und Leerzeichen verschwinden, die Groß-/Kleinschreibung spielt keine Rolle, und erst nach der Bereinigung verlangt der Parser Hexadezimalzeichen. Gemischte Schreibweise innerhalb einer Zeichenkette – 6C neben 6c – ist in Ordnung, weil beide Schreibweisen dieselbe Nibble-Wert bezeichnen.

Eingabe mit ungerader Länge: die explizite Richtlinie

Eine Hex-Zeichenkette mit ungerader Länge kann nicht ohne Raten geparst werden, weil ein Zeichen fehlt und sowohl am Anfang als auch am Ende ein plausibler Verlustort ist. Ein vorangestelltes Null und ein angehängtes Null erzeugen unterschiedliche Bytes – 0x48 versus 0x84 – also würde eine stille Korrektur eine Bedeutung zufällig auswählen und Ihnen Daten geben, die richtig aussehen. Die Richtlinie dieses Konverters ist es, abzulehnen: eine Eingabe mit ungerader Länge gibt einen benannten Fehler mit der Länge zurück, und die Reparatur obliegt demjenigen, der weiß, wo das Zeichen tatsächlich verloren ging. Es ist dieselbe ablehne-statt-verzerren-Regel, die die restlichen Konverter dieser Seite anwenden.

Wie die Ausgabe aussieht

Das Arbeitsbeispiel unten ist das exakte Paar, das der Button Beispielladung erzeugt: eine verzierte Hex-Zeichenkette – 0x-Präfix, Leerzeichen, gemischte Schreibweise – die als fünf Bytes, die „Hello“ buchstabieren, ankommt und als Standard-Base64 SGVsbG8= wiedergeht, mit einem =, weil die letzte Gruppe zwei Bytes statt drei trägt. Die Ausgabe verwendet das Standardalphabet, Plus und Schrägstrich eingeschlossen, nicht die URL-sichere Variante; wenn Ihr Ziel diese beiden Zeichen verändert, ist das URL-sichere Alphabet von RFC 4648 die dokumentierte Ersetzung, die danach angewendet werden muss.

Häufig gestellte Fragen

Wandelt der Konverter Hex in Base64 hoch, indem er meine Eing irgendwo hochlädt?

Nein. Das Parsen und die Kodierung laufen in diesem Browser-Tab in Code, der mit der Seite ausgeliefert wurde. Die Seite definiert keinen Upload-Endpunkt, und ihre Content-Security-Policy blockiert ausgehende Verbindungen, also ist ein Datendiebstahl strukturell unmöglich, nicht nur versprochen. DevTools macht die Behauptung überprüfbar: öffnen Sie das Network-Panel, wandeln Sie eine Zeichenkette um, und beobachten Sie, dass es nichts aufzeichnet.

Warum wird ungerade Hex-Eingabe statt zu korrigieren zurückgewiesen?

Weil jede Korrektur ein Raten mit echten Folgen ist. Eine ungerade Zeichenanzahl bedeutet, dass eine Nibble fehlt, und das Auffüllen mit einer Null vorne oder hinten ergibt unterschiedliche Bytes – 48 versus 84 – also würde eine stille Reparatur Daten erfinden, die plausibel aussehen. Der Konverter gibt einen benannten Fehler mit der Länge zurück, und Sie korrigieren die Quelle, wo das Zeichen tatsächlich verloren ging.

Werden Großbuchstaben, 0x-Präfixe und Leerzeichen wirklich akzeptiert?

Ja. Die Groß-/Kleinschreibung ist irrelevant – 4C und 4c sind dieselbe Nibble – 0x- und 0X-Präfixe werden entfernt, selbst wenn sie vor jedem Byte wiederholt werden, und alle Leerzeichen werden vor dem Parsen entfernt, also kann eine eingefügte Hex-Spalte ohne vorheriges Bereinigen umgewandelt werden. Nach der Bereinigung sind nur 0–9 und a–f oder A–F gültig; ein fremdes g oder ein Komma ist ein benannter Fehler mit seiner Position.

Enthält die Ausgabe immer =-Padding?

Padding erscheint nur, wenn die Byte-Anzahl nicht ein Vielfaches von drei ist – ein = für einen Rest von zwei Bytes, zwei für einen Rest von einem Byte – und die Ausgangslänge ist immer ein Vielfaches von 4. Die =-Zeichen sind Teil von RFC 4648, kein Rauschen: ihr Entfernen bricht Decoder, die von der Länge abhängen. Dieses Tool gibt die gepaddete Standardform aus, die mit dem übereinstimmt, was Standard-Encoder erzeugen.

Warum ist die Base64-Ausgabe kürzer als die Hex-Eingabe?

Kodierungs-Overhead-Arithmetik: hex verbraucht 2 Zeichen pro Byte, Base64 verbraucht 4 pro 3. Für dieselben Bytes läuft hex bei 100 Prozent Overhead und Base64 bei etwa 33 Prozent, also fällt ein 64-Byte-Digest von 128 Hex-Zeichen auf 88 Base64-Zeichen inklusive Padding. Die Daten sind identisch – nur die Packungseffizienz des Alphabets hat sich geändert.

Ist Base64-Kodierung eine Möglichkeit, Daten zu verschlüsseln?

Nein, und sie als solche zu behandeln ist ein echter Sicherheitsfehler. Base64 ist eine reversible Kodierung ohne Schlüssel: jeder, der die Zeichenkette hält, kann sie offline in Millisekunden dekodieren – diese Seite tut es ohne Netzwerk. Sie existiert, um Bytes durch text-sichere Kanäle zu bewegen, nicht um sie zu schützen. Wenn Vertraulichkeit wichtig ist, verschlüsseln Sie zuerst, dann kodieren Sie den Chiffretext mit Base64 für den Transport.

ToolsByUs-Team · Wie wir unsere Tools prüfen