Décoder Base64 / Encoder Base64

Qu’est-ce que l’encodage Base64 ?

Le Base64 est un encodage binaire-vers-texte : il représente n’importe quelles données à l’aide d’un alphabet de 64 caractères (A–Z, a–z, 0–9, + et /). Il permet à du contenu binaire de circuler sans dommage dans des canaux prévus pour du texte : e-mail, JSON, XML et URI data:. Ce n’est ni une compression ni un chiffrement — seulement une autre façon d’écrire les mêmes octets. La requête s’écrit souvent sans accent, « decoder base64 » ; c’est exactement la même opération que celle décrite ici.

Comment décoder ou encoder du Base64 ?

1. Collez votre contenu dans le champ Entrée.
2. Cliquez sur Encoder en Base64 pour convertir du texte, ou sur Décoder le Base64 pour repasser du Base64 en texte.
3. Récupérez le résultat avec Copier le résultat, ou renvoyez-le dans le champ de saisie avec Utiliser le résultat comme entrée pour enchaîner deux opérations.

L’outil encode via UTF-8 : le texte Unicode, les lettres accentuées et les emoji font donc l’aller-retour sans perte. Au décodage, les espaces et les retours à la ligne sont retirés automatiquement, ce qui évite l’erreur la plus fréquente quand on colle du Base64 recopié depuis un e-mail ou un certificat.

Un exemple complet : « Café » en Base64

Prenons le mot Café. Il compte 4 caractères mais 5 octets en UTF-8 — 67 97 102 195 169 — parce que le é s’écrit sur deux octets. Ces 5 octets donnent une chaîne Base64 de 8 caractères :

• Encoder : Café → Q2Fmw6k=
• Décoder : Q2Fmw6k= → Café
• Le = final est un remplissage : 5 octets ne sont pas un multiple de 3.

Vous pouvez le vérifier tout de suite : collez Q2Fmw6k= dans le champ Entrée, cliquez sur Décoder le Base64, et le mot Café apparaît. Le même principe sert à convertir base64 dans les deux sens — de base64 en texte, ou de texte en base64 — sans jamais perdre un octet en route.

Comment fonctionne réellement l’encodage Base64 ?

Le Base64 traite l’entrée par tranches de trois octets. Trois octets valent 24 bits, et 24 se divise exactement en quatre groupes de six bits. Chaque groupe de 6 bits — un sextet — porte une valeur de 0 à 63, ce qui suffit précisément à désigner une position dans un alphabet de 64 caractères. Ainsi, 3 octets d’entrée deviennent 4 caractères de sortie, et la sortie n’utilise que des symboles imprimables.

L’alphabet de 64 caractères, dans l’ordre, est le suivant :

• A–Z pour les valeurs 0–25
• a–z pour les valeurs 26–51
• 0–9 pour les valeurs 52–61
• + pour 62 et / pour 63

Un exemple déroulé à la main rend la chose concrète. Les trois lettres Man sont les octets 77 97 110, soit en binaire 01001101 01100001 01101110. Regroupés en sextets, cela donne 010011 010110 000101 101110 — les valeurs 19 22 5 46 — qui correspondent à T W F u. Donc Man s’encode en TWFu. Le décodage ne fait qu’inverser les étapes : quatre caractères redeviennent quatre sextets, concaténés en 24 bits, puis redécoupés en les trois octets d’origine.

Une entrée fait rarement un multiple exact de trois octets. Le Base64 utilise donc le caractère = comme remplissage (padding) pour indiquer combien d’octets réels contenait le dernier groupe :

• Groupe complet de 3 octets → 4 caractères, aucun remplissage.
• 2 octets restants (16 bits) → 3 caractères plus un =.
• 1 octet restant (8 bits) → 2 caractères plus deux ==.

Ce remplissage n’a rien de décoratif : il indique au décodeur d’écarter les bits à zéro ajoutés pour compléter le dernier sextet, afin que le nombre d’octets d’origine soit rétabli exactement.

Comment les accents (é, à, ç) passent-ils en Base64 ?

C’est le point qui fait échouer le plus de conversions en français. Le Base64 ne connaît pas les « caractères » : il ne connaît que des octets. Il faut donc décider avant quelle table de caractères transforme la lettre en octets, et l’Internet moderne a tranché : c’est UTF-8.

• En UTF-8, é vaut deux octets, 195 169, et s’encode en w6k=.
• En Latin-1 (ISO-8859-1), le même é vaut un seul octet, 233, et s’encode en 6Q==.

Les deux chaînes sont du Base64 parfaitement valide, mais elles ne décrivent pas les mêmes octets. Décodez 6Q== en supposant de l’UTF-8 et vous obtenez le caractère de remplacement U+FFFD, ce losange à point d’interrogation ; c’est la même famille de dégâts que les é qui polluent les exports mal configurés. Cet outil encode et décode toujours en UTF-8, donc é donne w6k= et w6k= redonne é. Si vous recevez du Base64 d’un système ancien et que les accents ressortent abîmés, le coupable est presque toujours le jeu de caractères d’origine, pas le Base64.

Autre conséquence pratique : une phrase française coûte plus de caractères qu’une phrase anglaise de même longueur. crème brûlée, 12 caractères, fait 15 octets en UTF-8 et donne Y3LDqG1lIGJyw7tsw6ll, soit 20 caractères Base64.

D’où vient le Base64 ?

Le Base64 est né d’un problème très précis : les débuts d’Internet transportaient le courrier sous forme de texte ASCII 7 bits. Le protocole SMTP d’origine supposait que chaque octet tenait sur sept bits, et de nombreux relais de messagerie supprimaient le huitième bit, dégradaient les caractères de contrôle ou réécrivaient les fins de ligne. Du binaire brut — une image, un programme, une archive compressée — ne survivait pas au voyage. Il fallait un moyen réversible de déguiser des octets quelconques en lettres et en chiffres ordinaires.

L’encodage apparaît d’abord dans Privacy-Enhanced Mail (PEM), publié comme RFC 1421 en février 1993, où il enveloppe des corps de message chiffrés dans du texte imprimable. Il touche un public bien plus large avec MIME, dont la première partie, RFC 2045, paraît en novembre 1996 et définit le Base64 comme Content-Transfer-Encoding standard des pièces jointes. La spécification moderne et consolidée est RFC 4648, « The Base16, Base32, and Base64 Data Encodings » (octobre 2006), qui rend obsolète l’ancienne RFC 3548 et sert aujourd’hui de référence à la plupart des logiciels.

Pourquoi le Base64 est-il environ 33 % plus gros ?

Puisque 3 octets deviennent 4 caractères, la sortie Base64 pèse toujours à peu près quatre tiers (4/3) de la taille de l’entrée — grosso modo une augmentation de 33 %. Le chiffre exact dépend de la longueur de l’entrée, de son reste dans la division par trois (le remplissage arrondit le dernier groupe à quatre caractères) et de la présence ou non de retours à la ligne. Un fichier de 9 Ko devient environ 12 Ko de texte ; une image de 3 Mo devient environ 4 Mo.

Si le texte encodé est replié en lignes — courant dans les e-mails — chaque retour à la ligne ajoute un ou deux caractères de plus, ce qui alourdit la sortie MIME typique d’encore 4 % environ. C’est le prix inévitable de la représentation de 256 valeurs d’octet possibles avec seulement 64 valeurs imprimables : il faut simplement plus de symboles pour dire la même chose. C’est aussi pourquoi le Base64 est un mauvais choix quand la bande passante ou le stockage sont comptés et que le canal sait déjà transporter du binaire directement.

Base64, Base64URL, Base32 ou hexadécimal : lequel choisir ?

Le Base64 standard utilise + et /, mais ces deux caractères sont gênants dans certains contextes : / est un séparateur de chemin et + signifie souvent « espace » dans les URL et les données de formulaire. La RFC 4648 §5 définit une variante « URL and filename safe », appelée d’ordinaire Base64URL, qui remplace ces deux caractères — - (moins) prend la place de + en position 62, et _ (tiret bas) celle de / en position 63. Le remplissage = est souvent omis lui aussi, car il peut lui aussi devoir être échappé. C’est le Base64URL que l’on retrouve dans les jetons JWT, dans les paramètres d’URL et dans les noms de fichiers.

La même RFC définit deux cousins qui sacrifient de la densité pour un alphabet plus petit, parfois plus sûr :

Choisissez l’hexadécimal quand vous voulez quelque chose de lisible par un humain et aligné trivialement sur les octets (chaque octet fait exactement deux chiffres hexadécimaux). Le Base32 quand le texte doit survivre à des systèmes insensibles à la casse, être lu à voix haute ou saisi à la main. Le Base64 ou le Base64URL quand c’est la densité qui prime — le cas le plus fréquent sur le Web.

Pourquoi les lignes font-elles 76 ou 64 caractères ?

Les anciens canaux textuels n’aimaient pas les lignes très longues, et deux conventions se sont imposées. MIME (RFC 2045) limite le Base64 à 76 caractères par ligne, tandis que PEM (RFC 1421) en utilise exactement 64 par ligne — le repliement que l’on voit encore dans les certificats TLS et les clés SSH, entre les marqueurs -----BEGIN----- et -----END-----. Ces lignes courtes maintenaient les messages dans les limites des logiciels de messagerie et des terminaux de l’époque.

Point essentiel : le repliement des lignes est une propriété du format environnant, pas du Base64 lui-même. La RFC 4648 est explicite : une implémentation « MUST NOT add line feeds to base-encoded data unless the specification referring to this document explicitly directs » de le faire. Une chaîne Base64 nue — celle que produit cet outil — est donc une seule ligne ininterrompue. Quand vous décodez du texte copié depuis un e-mail ou un certificat, les sauts de ligne et les espaces doivent être retirés au préalable ; cet outil le fait automatiquement.

À quoi sert le Base64 au quotidien ?

Dès lors que l’on sait transformer n’importe quels octets en texte sûr, les usages se multiplient. Les plus courants :

• Pièces jointes des e-mails (MIME). Chaque image, PDF ou document joint à un e-mail voyage encodé en Base64 — l’usage d’origine, celui qui a rendu ce format omniprésent.
• URI data:. Un fichier entier peut être intégré en ligne sous la forme data:[mediatype];base64,<données>, ce qui permet à une page de transporter une petite icône, une police ou une image sans requête HTTP supplémentaire. Ainsi data:text/plain;charset=utf-8;base64,Q2Fmw6k= affiche simplement Café. Les contreparties sont les 33 % de taille en plus et la perte de la mise en cache séparée : une ressource intégrée ne peut pas être mise en cache ni réutilisée indépendamment du document qui la contient. À réserver aux petits fichiers qui changent rarement.
• Intégration d’images dans le CSS et le HTML. La même astuce data: place des images de fond, des SVG et des polices web directement dans une feuille de styles.
• Du binaire dans JSON et XML. Aucun de ces deux formats ne sait contenir d’octets bruts ; les champs binaires — fichiers téléversés, vignettes, clés cryptographiques — y voyagent donc sous forme de chaînes Base64.
• Authentification HTTP Basic. L’en-tête Authorization: Basic transporte le Base64 de identifiant:mot de passe. Par exemple Aladdin:open sesame devient QWxhZGRpbjpvcGVuIHNlc2FtZQ== (défini dans la RFC 7617).
• Jetons JWT. L’en-tête, la charge utile et la signature d’un JWT sont chacun encodés en Base64URL et reliés par des points, ce qui produit un jeton compact et compatible avec les URL.

Le Base64 est-il un chiffrement ?

Non, et c’est la chose la plus importante à retenir. Le Base64 n’apporte aucune sécurité. C’est une correspondance publique et réversible, sans clé — n’importe qui peut décoder n’importe quelle chaîne Base64 instantanément, exactement comme le fait cette page. Il ne cache pas, ne brouille pas et ne protège pas les données ; il change seulement la représentation d’octets déjà connus.

Deux exemples quotidiens le prouvent. L’authentification HTTP Basic envoie votre mot de passe en Base64, et c’est pour cela que la RFC 7617 insiste : elle « does not provide confidentiality » et doit toujours passer par HTTPS/TLS, puisque le Base64 se décode trivialement pour quiconque observe la connexion. De même, les revendications d’un JWT signé sont encodées en Base64URL, pas chiffrées : collez le segment du milieu dans un décodeur et vous lisez chaque champ. Une signature JWT prouve que le jeton n’a pas été altéré, mais elle ne rend rien secret.

Et contrairement à la compression, le Base64 rend les données plus grosses, pas plus petites. S’il vous faut de la confidentialité, chiffrez les données (vous pourrez ensuite encoder le texte chiffré en Base64 pour le transport). S’il vous faut une charge utile plus légère, compressez-la. Le Base64 ne sert qu’au transport sûr à travers des canaux purement textuels — rien de plus.

Quelles sont les erreurs les plus fréquentes ?

• Oublier l’UTF-8 pour le texte accentué. Dans le navigateur, la fonction classique btoa() travaille octet par octet et lève une erreur sur tout caractère dont le point de code dépasse 0xFF : un emoji ou une lettre accentuée suffit à casser un code naïf. La solution est de convertir d’abord la chaîne en ses octets UTF-8, puis d’encoder ces octets. C’est exactement ce que fait cet outil, d’où l’aller-retour fidèle des accents, des alphabets non latins et des emoji.
• Les espaces et les sauts de ligne au décodage. Le Base64 copié depuis un e-mail, un certificat ou un fichier de configuration contient souvent des retours à la ligne et des espaces, que beaucoup de décodeurs refusent. Retirez tous les blancs avant de décoder (cet outil s’en charge automatiquement).
• Un remplissage manquant ou faux. Certaines sources, en particulier en Base64URL, suppriment les = de fin. Les décodeurs stricts échouent alors, tandis que les décodeurs tolérants rétablissent le remplissage déduit de la longueur de la chaîne. Si un décodage échoue, vérifiez que le nombre de caractères est un multiple de quatre.
• Confondre les deux alphabets. Donner du Base64URL (- et _) à un décodeur Base64 standard — ou l’inverse — corrompt le résultat. Remplacez - par + et _ par / (ou réciproquement) avant de décoder.
• Le prendre pour une protection. Comme expliqué plus haut, n’utilisez jamais le Base64 pour « cacher » un secret. C’est un encodage, pas un chiffrement.

Questions fréquentes

Comment décoder une chaîne Base64 ?

Collez-la dans le champ Entrée puis cliquez sur « Décoder le Base64 ». L’outil retire d’abord les espaces et les retours à la ligne, puis relit les octets en UTF-8 pour vous rendre le texte d’origine. Par exemple, Q2Fmw6k= redonne Café.

Mes données sont-elles envoyées quelque part ?

Non. L’encodage et le décodage se font entièrement dans votre navigateur, en JavaScript. Votre texte ne quitte jamais votre appareil.

Les accents et les emoji sont-ils gérés correctement ?

Oui. Le texte est d’abord converti en octets UTF-8, donc é, à, ç, les alphabets non latins et les emoji font l’aller-retour sans perte. La lettre é devient w6k= et redonne bien é.

Le Base64 protège-t-il mes données ?

Non. Le Base64 n’est pas un chiffrement : c’est une correspondance publique et réversible, sans clé. N’importe qui peut décoder une chaîne Base64 en une seconde, exactement comme le fait cette page.

À quoi sert le Base64 ?

Le Base64 représente des données binaires sous forme de texte ASCII, pour qu’elles traversent sans dommage des systèmes conçus pour du texte : e-mail (MIME), JSON, XML, URI data: et en-têtes HTTP.

Outils similaires

• Image en Base64 (URI data:)
• Encoder / décoder une URL
• Décoder un jeton JWT
• Générateur de hachage (MD5, SHA-1, SHA-256)
• Formateur JSON
• Voir tous les outils