Base64 vs Hex

Mêmes octets, deux alphabets

Les deux encodages résolvent un même problème : les octets sont des valeurs de 8 bits, mais les transports de texte — URL, en-têtes, XML, JSON, e-mail — préfèrent l’ASCII imprimable. L’hexadécimal puise dans les seize caractères 0-9 et a-f ; base64 puise dans A-Z, a-z, 0-9, + et /. Aucun des deux ne chiffre ni ne compresse quoi que ce soit : tous deux sont publiquement spécifiés, sans clé et instantanément réversibles, et une chaîne base64 est une sécurité de transport, pas de la sécurité.

L’arithmétique : un tiers contre un doublement

L’hexadécimal est aligné sur les demi-octets : un octet se scinde en deux moitiés de 4 bits, chacune rendue comme un caractère, donc les longueurs sont prévisibles — une valeur de n octets fait toujours 2n caractères, sans padding ni cas particuliers. Base64 regroupe les bits en tranches de 6 bits, et 24 bits est le premier point où le monde des octets et celui de base64 s’alignent, si bien que trois octets deviennent quatre caractères. Un octet restant se complète avec ==, deux avec un seul =.

Un exemple en paire rend le ratio concret : les octets de « Hi » s’écrivent 48 69 en hexadécimal — quatre caractères — et SGk= en base64 — quatre caractères également, padding compris. Aux tailles réelles, l’écart devient dominant : un mégaoctet de données devient environ 1.33 MB en base64 avec padding, mais exactement 2 MB en hexadécimal, d’où la standardisation de base64 pour le transport en masse tandis que les valeurs courtes restaient hexadécimales.

Là où chaque encodage s’est installé

Base64 règne sur le volume et le transport. MIME l’emploie pour les pièces jointes d’e-mail, l’authentification HTTP Basic encode les identifiants avec lui, les JWT passent leur en-tête, leur charge utile et leur signature en base64url, les data: URIs intègrent images et polices directement dans les pages et les feuilles de style, et les cookies transportent des valeurs base64url parce que + et / se comportent mal dans les URL et les en-têtes. Partout où du binaire doit survivre à un tuyau purement textuel au moindre coût, base64 est la réponse.

L’hexadécimal règne sur le petit et le vérifié à l’œil. Les empreintes cryptographiques s’impriment en hexadécimal par convention — sorties SHA-256, identifiants de commit git — parce que des paires de largeur fixe, sans padding et alignées sur les octets se comparent trivialement à l’œil ou à voix haute. Les adresses MAC, la forme textuelle des UUID et les couleurs CSS comme #RRGGBB sont toutes hexadécimales, et les éditeurs hexadécimaux, dumps mémoire et débogueurs de protocole l’emploient parce que chaque octet s’y lit comme une unité autonome.

Pièges et critères de choix

Les pièges de base64 tiennent tous à l’alphabet. Les variantes standard et URL-safe diffèrent de deux caractères et ne doivent jamais être mélangées ; le padding est exigé par les décodeurs stricts mais supprimé par la convention JWT ; la sortie est sensible à la casse ; et MIME coupe les lignes à 76 caractères. L’hexadécimal n’en a qu’un : la casse. Les minuscules sont la convention et les majuscules apparaissent dans certains outils, mais les mélanger est purement cosmétique — tout décodeur strict accepte les deux.

Donc : choisissez base64 quand le volume compte ou qu’un protocole l’exige — pièces jointes, jetons, binaire embarqué. Choisissez l’hexadécimal pour les valeurs courtes que des humains compareront, copieront ou débogueront : empreintes, identifiants, couleurs. Le choix s’inverse sans cesse dans les systèmes réels — un JWT arrive en base64url et son empreinte SHA-256 est hexadécimale — et les convertisseurs ci-dessous assurent la traversée dans votre navigateur.