BrowserTools
Publicité
Accueil / Encodeurs / Encodeur et décodeur Base64

Encodeur et décodeur Base64

Encodez et décodez du texte ou des fichiers en Base64 localement dans votre navigateur.

Chargement de Encodeur et décodeur Base64… Si rien ne se passe, activez JavaScript.

Le Base64 est un schéma d'encodage du binaire vers le texte qui représente des données binaires à l'aide de seulement 64 caractères ASCII imprimables : les lettres latines majuscules et minuscules, les chiffres de 0 à 9 et les symboles + et /. Il a été normalisé en 1987 dans le cadre du RFC 989 pour le courrier à confidentialité renforcée (Privacy Enhanced Mail), puis formalisé dans le RFC 4648. Le nom vient du fait que chaque caractère de sortie encode exactement 6 bits, ce qui signifie que chaque 3 octets d'entrée binaire deviennent exactement 4 caractères ASCII, une surcharge de 33 % qui vaut bien le gain de compatibilité.

Exemples

Entrée Hello, World!
Sortie SGVsbG8sIFdvcmxkIQ==

Base64 standard d'un texte UTF-8.

Entrée Café
Sortie Q2Fmw6k=

Ce qui n'est pas ASCII est d'abord encodé en UTF-8 : é devient les octets 0xC3 0xA9.

Entrée SGVsbG8sIFdvcmxkIQ==
Sortie Hello, World!

Le décodage inverse exactement la transformation.

Questions fréquentes

Mes données sont-elles envoyées à un serveur ?
Non. Tout l'encodage et le décodage se font localement dans votre navigateur à l'aide des API intégrées btoa/atob et FileReader de la plateforme web. Votre texte, vos fichiers et toute valeur sensible ne quittent jamais votre appareil et ne sont jamais transmis sur le réseau.
Quels sont exactement ces 64 caractères qu'utilise le Base64 ?
L'alphabet standard défini dans le RFC 4648 utilise A-Z (26 caractères), a-z (26 caractères), 0-9 (10 caractères), plus + et /, soit 64 au total. Le caractère = sert de remplissage pour que la longueur de la sortie soit un multiple de 4. La variante adaptée aux URL remplace + par - et / par _ afin que la sortie soit sûre dans les URL et les noms de fichiers sans échappement supplémentaire.
Quand devrais-je utiliser l'encodage Base64 dans mes propres projets ?
Utilisez le Base64 chaque fois que vous devez intégrer des données binaires dans un format en texte seul : intégrer des images en Data URI dans du HTML ou du CSS, stocker des blobs binaires en JSON ou XML, envoyer des fichiers dans le corps d'une API JSON ou inclure des clés cryptographiques dans des variables d'environnement. Évitez-le quand vous pouvez utiliser un transport capable de gérer le binaire, car le Base64 ajoute une surcharge de 33 %.
Comment le Base64 se compare-t-il à l'encodage hexadécimal ?
Les deux convertissent des données binaires en texte imprimable, mais diffèrent par la densité. L'hexadécimal utilise 2 caractères par octet (50 % de surcharge), tandis que le Base64 utilise environ 1,33 caractère par octet (33 % de surcharge), ce qui rend le Base64 environ 25 % plus compact. L'hexadécimal est plus facile à lire et très utilisé pour les sommes de contrôle et les codes de couleur ; le Base64 est préféré quand la compacité compte ou quand la sortie sera intégrée dans des formats de texte structurés.
Quelle est la taille maximale de fichier que je peux encoder ou décoder ?
Il n'y a pas de limite codée en dur, mais des contraintes pratiques s'appliquent. Les très gros fichiers (des dizaines de mégaoctets) sont conservés entièrement en mémoire du navigateur sous forme de chaîne, ce qui peut entraîner des ralentissements ou des erreurs de mémoire insuffisante sur les appareils peu dotés en RAM. Pour la plupart des cas, jusqu'à quelques mégaoctets, l'outil est rapide et réactif. Pour les traitements en masse ou les gros fichiers, un outil en ligne de commande comme base64 (Linux/macOS) ou certutil -encode (Windows) est plus approprié.
Fonctionne-t-il hors ligne et dans tous les navigateurs modernes ?
Oui. L'outil n'utilise que des API web standard (btoa, atob, FileReader, TextEncoder) disponibles dans tous les principaux navigateurs depuis 2012. Il n'y a aucune requête externe, il fonctionne donc entièrement hors ligne une fois la page chargée. Les performances dépendent du processeur et de la RAM disponible de votre appareil.
Puis-je encoder des fichiers binaires comme des images ou des PDF ?
Oui. Utilisez l'entrée de fichier pour sélectionner n'importe quel fichier binaire. L'API FileReader le lit comme un ArrayBuffer, qui est ensuite converti en chaîne Base64 sans aucun problème d'encodage de caractères. La chaîne obtenue peut être collée directement dans un Data URI (préfixez-la par data:image/png;base64, pour un PNG, par exemple) ou utilisée partout ailleurs où l'on attend du binaire encodé en Base64.
Le Base64 est-il une forme de chiffrement ?
Non, le Base64 est purement un schéma d'encodage, pas un chiffrement. Il n'offre aucune confidentialité : quiconque voit la chaîne encodée peut la décoder instantanément sans aucune clé ni mot de passe. N'utilisez pas le Base64 pour protéger des données sensibles. Utilisez un chiffrement adéquat (AES, RSA, etc.) pour la confidentialité, et n'employez le Base64 que comme format de transport ou de stockage une fois les données chiffrées.
Quelle est la différence entre le Base64 standard et le Base64url ?
Le Base64 standard (RFC 4648, section 4) utilise + et / comme 62e et 63e caractères, qui ont une signification particulière dans les URL et doivent être encodés pour cent. Le Base64url (RFC 4648, section 5) remplace + par - et / par _, ce qui rend la sortie sûre à inclure dans les URL, les noms de fichiers et les en-têtes HTTP sans échappement. Les JSON Web Token utilisent toujours Base64url. Le commutateur de mode adapté aux URL de cet outil applique cette substitution automatiquement.
Pourquoi obtiens-je parfois une erreur de « caractère non valide » au décodage ?
Cela signifie généralement que l'entrée contient des caractères hors de l'alphabet Base64, souvent des espaces, des sauts de ligne ou un préfixe de Data URI comme « data:image/png;base64, ». Retirez tout préfixe de ce type avant de décoder. Une autre cause fréquente est une chaîne encodée pour URL où le + a été remplacé par un espace ; dans ce cas, passez en mode adapté aux URL ou remplacez manuellement les espaces par des + avant de décoder.

À propos de Encodeur et décodeur Base64

Les développeurs recourent au Base64 tous les jours sans toujours s'en rendre compte. Les Data URI qui intègrent des images ou des polices directement dans le HTML et le CSS utilisent Base64. Les JSON Web Token utilisent Base64url (une variante adaptée aux URL) pour empaqueter leur en-tête et leur charge utile. L'authentification HTTP basique encode les identifiants en Base64 avant de les placer dans l'en-tête Authorization. Les certificats TLS, les clés SSH et les messages PGP en armure sont tous distribués sous forme de fichiers PEM enveloppés en Base64. Chaque fois que des données binaires doivent survivre à une couche de transport ou de stockage en texte seul (courrier, JSON, XML, variables d'environnement), Base64 est la réponse standard.

Cet outil encode et décode le Base64 entièrement dans votre navigateur. Il utilise les fonctions btoa/atob intégrées de la plateforme pour le texte et l'API FileReader pour le téléversement de fichiers binaires. Comme tout le traitement se fait sur votre propre appareil, vos données ne sont jamais transmises à aucun serveur, ce qui permet de l'utiliser en toute sécurité avec des identifiants sensibles, des clés privées ou des documents confidentiels. L'outil prend aussi en charge le Base64 adapté aux URL, qui remplace + par - et / par _ afin que la sortie puisse être intégrée dans des URL sans encodage pour cent.

Quelques points d'attention : btoa lève une TypeError si l'entrée contient des caractères hors de la plage Latin-1, c'est pourquoi l'outil encode automatiquement le texte Unicode en UTF-8 avant de l'encoder. Au décodage, les caractères de remplissage finaux (=) sont facultatifs dans de nombreuses implémentations, mais certains analyseurs stricts les exigent ; si vous obtenez une erreur de décodage, essayez d'ajouter un ou deux signes =. Le Base64 est un encodage, pas un chiffrement : il n'offre aucune confidentialité, et n'importe qui peut le décoder instantanément. Ne stockez jamais de mots de passe ou de jetons en Base64 en espérant un quelconque bénéfice de sécurité.

Les origines du Base64

Le Base64 a été normalisé en 1987 dans le cadre du RFC 989, qui définissait le courrier à confidentialité renforcée (PEM) pour l'échange sécurisé de courrier électronique. Le nom vient du fait que l'encodage utilise exactement 64 caractères ASCII imprimables, le plus grand sous-ensemble en puissance de deux qui tient confortablement dans la plupart des encodages de caractères de l'époque. Le schéma a ensuite été affiné dans le RFC 1421 puis documenté définitivement dans le RFC 4648 (2006), qui reste la référence faisant autorité aujourd'hui.

Avant le Base64, envoyer des données binaires par les systèmes de courrier était notoirement peu fiable. Les premiers relais de courrier fonctionnaient en ASCII 7 bits et corrompaient en silence les octets supérieurs à 127, les traitant comme des codes de contrôle ou supprimant carrément le bit de poids fort. Le Base64 a résolu cela en faisant correspondre chaque 3 octets d'entrée binaire à 4 caractères imprimables tirés d'un sous-ensemble d'ASCII sûr et universellement pris en charge, garantissant un transit fidèle par n'importe quel canal en texte seul.

Aujourd'hui, le Base64 est tissé dans la trame du web. Un navigateur moderne traite des milliers d'opérations Base64 par chargement de page sans que l'utilisateur le remarque : décodage de fichiers de polices intégrés au CSS, vérification de jetons JWT dans les réponses d'API, affichage d'images en ligne dans les clients de messagerie et validation de certificats TLS lors de la poignée de main HTTPS. Ce qui a commencé comme un contournement d'une infrastructure de courrier défaillante des années 1980 est devenu l'un des encodages les plus discrètement essentiels de l'informatique.

Publicité
Publicité
Publicité