Aller au contenu principal
ToolsByUs

Base64 vers hexadécimal

Ce décodeur convertit le Base64 selon la RFC 4648 et ré-encode les mêmes octets en hexadécimal minuscule dans votre navigateur. Le padding est géré, l’alphabet URL-safe est accepté, et chaque octet correspond à exactement deux chiffres hexadécimaux dans l’ordre de sortie : aucun préfixe, aucun séparateur, aucun envoi.

100 % local

Base64 vers hexadécimal en clair

Base64 et hex sont deux représentations des mêmes octets, et ce convertisseur passe de l’un à l’autre : décode le Base64 exactement comme la RFC 4648 le prescrit, puis affiche chaque octet décodé comme deux chiffres hexadécimaux minuscules. Rien n’est réinterprété en cours de route — ce que vous obtenez est la séquence d’octets qu’un éditeur hexadécimal vous montrerait, caractère par caractère.

Les parties intéressantes sont celles que les convertisseurs ignorent habituellement. Padding : les caractères = de fin sont gérés, et l’entrée dont un pipeline a supprimé le padding est également acceptée. Alphabets : l’ensemble standard A-Z a-z 0-9 + / est décodé, et la variante URL-safe -_ définie par la même RFC est normalisée avant décodage. Ordre des octets : préservé — un octet devient deux chiffres hexadécimaux, le quartet de poids fort d’abord, toujours.

Comme tous les outils de ce site, la conversion s’exécute dans cet onglet de navigateur : votre texte ne quitte jamais la machine, aucune requête n’est envoyée, et la politique de sécurité du contenu (Content-Security-Policy) interdit à la page de se connecter nulle part. Le fait que le panneau Réseau des DevTools reste vide pendant la conversion est la preuve, pas la promesse.

Le trajet inverse — octets affichés en hexadécimal, destinés à un en-tête ou un champ de jeton — est ce que l’outil sœur convertisseur Hex vers Base64 effectue, avec le même alphabet RFC 4648 et le même traitement local.

Si les règles de regroupement et de padding vous semblent arbitraires, le guide sur comment le Base64 fonctionne réellement construit l’ensemble du mécanisme depuis les principes de base en trois paragraphes courts.

Comment la conversion fonctionne réellement

La conversion se déroule en deux étapes bien définies, sans rien de caché entre elles, et chaque étape a une politique à laquelle vous pouvez la tenir :

  • Normaliser : les espaces, les sauts de ligne (entrée au format MIME) et un point d’interrogation initial sont supprimés ; les caractères URL-safe - et _ sont mappés à + et / selon le deuxième alphabet de la RFC 4648.
  • Décoder : les caractères restants passent par l’alphabet RFC 4648 — 4 caractères vers 3 octets — avec le padding = consommé au dernier quantum.
  • Valider : tout caractère en dehors de l’alphabet est une erreur nommée avec sa position ; une longueur de 1 de plus qu’un multiple de 4 est rejetée catégoriquement, car un seul caractère résiduel ne peut former un octet de manière valide.
  • Émettre : chaque octet devient deux chiffres hexadécimaux minuscules, le quartet de poids fort d’abord, concaténés sans séparateurs et sans préfixe 0x.

Padding et alphabets, précisément

L’alphabet standard de la RFC 4648 est A-Z, a-z, 0-9, + et /, avec un padding = pour le dernier quantum lorsque le nombre d’octets n’est pas un multiple de 3. Le padding est significatif — il dissocie un quantum final d’un octet de deux — mais le décodeur accepte également une entrée sans padding lorsque la longueur rend le quantum non ambigu (longueurs de 2 ou 3 mod 4). Une longueur de 1 mod 4 est invalide, avec ou sans padding — un seul caractère Base64 ne peut pas produire un octet entier — et est rejeté plutôt que complété par des zéros.

La variante URL-safe définie par la même RFC — trait de soulignement et tiret à la place du plus et du slash — est acceptée et normalisée, ce qui est important en pratique car les JWT et les paramètres d’URL sont généralement émis sans padding et en URL-safe. Mélanger les deux alphabets dans une même entrée est rejeté : une chaîne contenant à la fois + et - n’a pas de lecture cohérente.

À quoi ressemble la sortie

L’exemple ci-dessous est la paire exacte que produit le bouton Charger un exemple : le Base64 pour « Hello world » rendu sous forme de 22 chiffres hexadécimaux minuscules — deux par octet, onze octets. La sortie est une chaîne continue — aucun préfixe 0x, aucun espace, aucun saut de ligne — car les éditeurs hexadécimaux, les analyseurs et le code préfèrent tous la forme simple. Le calcul de longueur : le Base64 utilise 4 caractères pour 3 octets, l’hexadécimal utilise 2 pour 1 octet, donc l’hexadécimal est environ 1,5 fois plus long que le Base64 non complété — une propriété des encodages, pas de vos données.

Ordre des octets, dit une fois pour toutes

La little-endianness n’intervient jamais, et il est utile d’expliquer pourquoi. Le Base64 se décode en une séquence d’octets, et une séquence a un ordre naturel : le premier octet décodé en premier. La sortie hexadécimale reflète cet ordre exactement — l’octet n devient les caractères hexadécimaux aux positions 2n et 2n+1 — donc le résultat est la même chaîne qu’un éditeur hexadécimal sans décalages afficherait. Il n’y a aucun échange de mots, aucune réinterprétation en little-endian, et aucune surprise lorsque vous comparez avec xxd.

Questions fréquentes

La conversion de Base64 en hexadécimal envoie-t-elle mes données quelque part ?

Non. Le décodage et le réencodage se produisent dans cet onglet de navigateur, en JavaScript qui a chargé avec la page. Il n’y a pas de route d’envoi dans le code de la page, et la politique de sécurité du contenu du site interdit les connexions sortantes. Pour le vérifier vous-même : ouvrez DevTools, effacez ou surveillez le panneau Réseau, convertissez, et observez qu’aucune requête n’apparaît — l’outil fonctionne même avec le réseau débranché.

La sortie hexadécimale est-elle en majuscules ou en minuscules ?

Toujours en minuscules — la même convention que xxd et la plupart des éditeurs hexadécimales. Les majuscules et minuscules en hexadécimal désignent des octets identiques, et une passe de mise en majuscules est sans perte si un système le demande. La sortie ne comporte aucun préfixe 0x, séparateur ou saut de ligne, donc elle se colle proprement dans le code, les analyseurs et les tests.

Pourquoi la chaîne hexadécimale est-elle plus longue que l’entrée Base64 ?

C’est une question d’arithmétique des deux encodages : le Base64 empaquette 3 octets dans 4 caractères (environ 33 % de surcharge), tandis que l’hexadécimal utilise 2 caracteurs pour chaque octet (100 % de surcharge). Divisez les deux et l’hexadécimal est environ 1,5 fois plus long que le Base64 non complété pour les mêmes octets. Aucun des encodages ne compresse quoi que ce soit — ce sont simplement deux alphabets sur la même séquence d’octets.

L’entrée a-t-elle besoin de son padding = ?

Non. L’entrée avec padding est décodée en l’état, et le padding qu’un pipeline aurait supprimé est reconstruit à partir de la longueur — une longueur de 2 ou 3 mod 4 identifie le dernier quantum de manière non ambiguë. La seule longueur qui est toujours invalide est 1 mod 4, avec ou sans padding, car un seul caractère Base64 ne peut pas produire un octet entier ; cette entrée est rejetée avec une erreur claire, jamais devinée.

La conversion de Base64 en hexadécimal est-une forme de décryptage ?

Non, et la distinction est importante. Le Base64 et l’hexadécimal sont tous deux des encodages : des représentations inversibles des mêmes octets, sans clé dans le processus. N’importe qui peut décoder l’un ou l’autre, y compris cette page, hors ligne. Si votre Base64 codait un texte chiffré, le convertir en hexadécimal ne change que la représentation — les données sont exactement aussi lisibles, ou aussi protégées, qu’avant.

Et le Base64 URL-safe avec les caractères - et _ ?

Accepté et géré. La RFC 4648 définit l’alphabet URL-safe — trait d’union pour le plus, tiret bas pour le slash — pour les contextes où + et / seraient maltraités, comme les JWT et les segments de chemin d’URL. Le convertisseur normalise ces caractères vers l’alphabet standard avant décodage, donc un jeton copié directement d’un en-tête Authorization fonctionne sans modification. Seul un mélange des deux alphabets est refusé.

Équipe ToolsByUs · Comment nous vérifions nos outils