Encodage et décodage Base64 en ligne, gratuits

Qu'est-ce que Base64 ?

Base64 est un schéma d'encodage binaire-vers-texte, une façon de représenter n'importe quelle séquence d'octets (données binaires) comme une séquence de caractères ASCII ordinaires qui peuvent traverser des canaux uniquement texte sans corruption. Le nom reflète la taille de l'alphabet : 64 caractères choisis spécifiquement parce qu'ils survivent à une transmission propre sur 7 bits sans modification. L'alphabet standard est A-Z (positions 0-25), a-z (26-51), 0-9 (52-61), puis + (62) et / (63). Le caractère = est réservé comme remplissage quand la longueur d'entrée n'est pas un multiple exact de trois. Chaque triplet d'octets en entrée (24 bits) devient quatre caractères en sortie (chacun portant 6 bits), c'est pourquoi les données encodées en Base64 sont environ 33 % plus volumineuses que l'original.

Le mécanisme : prenez trois octets (24 bits), regroupez-les en quatre tranches de 6 bits, recherchez chaque tranche dans l'alphabet de 64 caractères. L'exemple classique : les trois octets ASCII M a n (0x4D 0x61 0x6E) forment le motif 24 bits 01001101 01100001 01101110 ; regroupés en tranches de 6 bits : 010011 010110 000101 101110 = 19, 22, 5, 46 en décimal = caractères T W F u. Donc "Man" s'encode en Base64 en "TWFu". Si la longueur d'entrée n'est pas divisible par trois, l'encodeur ajoute un ou deux = en remplissage : 1 octet en entrée produit 2 caractères + ==, 2 octets en entrée produisent 3 caractères + =.

Une brève histoire de Base64

Base64 est né de l'effort Privacy Enhanced Mail (PEM) de l'IETF. RFC 989 en février 1987 en est la première définition formelle ; RFC 1113 en août 1989 la révise ; RFC 1421 en février 1993 finalise la spécification PEM avec l'encodage Base64 inclus. Base64 entre dans la messagerie grand public quand la spécification MIME (Multipurpose Internet Mail Extensions) l'adopte : RFC 2045 en novembre 1996 définit Base64 comme l'encodage standard pour les pièces jointes binaires d'e-mail, c'est pourquoi chaque PDF ou image que vous avez attaché à un e-mail a traversé le réseau en Base64. La spécification canonique actuelle est RFC 4648 (« The Base16, Base32, and Base64 Data Encodings »), publiée en octobre 2006 par Simon Josefsson, qui remplace RFC 3548 (juillet 2003) et unifie les divers encodages de la famille Base16 / Base32 / Base64 dans un seul document. RFC 4648 est la spec que toute implémentation moderne de Base64 vise.

Base64 URL-safe, pourquoi deux caractères sont échangés

L'alphabet standard de Base64 utilise + et /, deux caractères réservés dans les URL. + dans une chaîne de requête URL signifie typiquement « espace » (convention form-encoded) ; / est le séparateur de chemin. Mettre du Base64 standard dans une URL implique de percent-encoder les deux, ce qui gonfle encore la chaîne et la rend laide. RFC 4648 §5 définit une variante URL-safe : remplacer + par - (trait d'union-moins) et / par _ (souligné). Parfois appelée Base64URL ou base64url. Le résultat est une chaîne qui se glisse directement dans les URL sans échappement supplémentaire, exactement ce qu'utilisent JWT (JSON Web Tokens), les paramètres state d'OAuth, les identifiants de credentials WebAuthn et la plupart des API web modernes. Certaines implémentations suppriment aussi le = final de remplissage parce que la longueur est implicite à partir du champ suivant. La structure en trois parties séparées par des points de JWT (en-tête.charge.signature) consiste en trois segments encodés en Base64URL ; si vous avez déjà décodé un JWT à la main, vous avez vu les caractères - et _ qui le marquent comme Base64URL plutôt que Base64 standard.

La famille Base-N, Base16, Base32, Base58, Base85

Base64 n'est pas le seul encodage binaire-vers-texte. Base16 (hexa) utilise 16 caractères (0-9 et A-F), 100 % d'expansion (chaque octet devient 2 caractères hexa), mais trivialement lisible et le défaut universel pour les sorties de hachage, sommes de contrôle et identifiants machine. Base32 (RFC 4648, variante de Crockford aussi) utilise 32 caractères en prenant soin d'exclure les paires visuellement ambiguës comme 0/O et 1/I/L ; 60 % d'expansion ; utilisé pour les clés secrètes TOTP, les ULID et les adresses Tor onion. Base58 est canonique pour Bitcoin : 58 caractères excluant les facilement confondus 0/O/I/l, plus les caractères spéciaux de Base64 standard +/=. Les adresses Bitcoin, les adresses Solana et de nombreux identifiants de portefeuilles crypto utilisent Base58Check (Base58 plus une somme de contrôle de 4 octets). Base85 / Ascii85 emballe plus de densité (encodant 4 octets en 5 caractères, seulement 25 % d'expansion) mais utilise un alphabet qui inclut de la ponctuation URL-unsafe ; les formats PostScript et PDF d'Adobe utilisent Base85 en interne pour les données binaires incorporées. L'arbitrage général : plus de caractères dans l'alphabet signifie moins d'expansion mais un jeu de caractères plus contraint ; moins de caractères signifie un transport plus sûr au prix d'une sortie plus volumineuse.

Utilisations courantes de Base64

• Pièces jointes d'e-mail (MIME). RFC 2045 depuis 1996. Chaque PDF, image ou document que vous avez attaché à un e-mail a traversé le réseau en Base64 parce que SMTP était à l'origine un protocole texte propre sur 7 bits qui ne pouvait pas gérer le binaire brut.
• URI data: en HTML/CSS. data:image/png;base64,iVBORw0KGgo... incorpore une petite image directement dans le HTML ou une feuille de style CSS, en éliminant une requête HTTP. Utile pour les icônes sous ~10 Ko ; contre-productif pour les images plus grandes parce que l'expansion Base64 de 33 % dépasse l'économie de surcoût de requête HTTP.
• Binaire dans les charges utiles JSON. JSON est text-only par spec, il n'y a pas moyen de mettre des octets bruts dans une valeur JSON. Les API qui doivent transmettre des images, PDF ou autre binaire les incorporent comme chaînes Base64 dans un champ JSON. Les charges utiles de webhooks Stripe, les API MMS de Twilio et beaucoup d'endpoints AI-vision utilisent ce schéma.
• JWT (JSON Web Tokens). Les trois parties séparées par des points d'un JWT (en-tête.charge.signature) sont toutes encodées en Base64URL. La spec JWT (RFC 7519, mai 2015) s'appuie sur JOSE (RFC 7515-7518, mai 2015 aussi), qui mandatent toutes Base64URL partout.
• OAuth et OpenID Connect. Le paramètre state, les code verifiers PKCE, les ID tokens et les access tokens dans de nombreuses implémentations utilisent Base64URL.
• Authentification HTTP Basic. L'en-tête Authorization: Basic dXNlcjpwYXNz porte Base64(utilisateur:motdepasse). Note : c'est de l'encodage pour le transport, PAS du chiffrement, Basic Auth en HTTP simple expose les identifiants en clair à quiconque observe le réseau. Toujours combiner avec HTTPS.
• Subresource Integrity (SRI). L'attribut integrity="sha384-..." sur les balises <script> et <link> porte un hachage encodé en Base64 du contenu attendu du fichier ; les navigateurs vérifient que le fichier téléchargé correspond avant exécution.
• Arrière-plans SVG dans CSS. background-image: url("data:image/svg+xml;base64,...") incorpore un SVG directement dans une feuille de style. La forme Base64 est parfois préférée à la forme URL-encoded (qui garde le SVG lisible mais utilise des règles d'échappement différentes).

L'encodage n'est pas le chiffrement, une erreur de sécurité courante

Base64 n'offre aucune sécurité. L'encodage est totalement réversible par quiconque en millisecondes, l'alphabet est public, l'algorithme est trivial, et n'importe quel navigateur ou commande CLI d'une ligne peut le décoder. Malgré cela, « données sensibles encodées en Base64 » est l'un des exemples les plus cités dans CWE-261 de MITRE (Weak Encoding for Password) et apparaît constamment dans les audits de sécurité : clés d'API « obscurcies » par Base64 dans du code client ; mots de passe « encodés » avec Base64 dans des sauvegardes de bases de données ; secrets « chiffrés » avec Base64 avant d'être committés dans un dépôt Git public. Aucun n'est protégé. Si vous avez besoin de confidentialité réelle, utilisez du vrai chiffrement : AES-256-GCM pour le symétrique, RSA-OAEP ou ECDH+ChaCha20-Poly1305 pour l'asymétrique. Base64 est approprié pour le transport (transformer du binaire en forme text-friendly) mais jamais pour la protection.

Implémentation navigateur : btoa / atob et le piège Unicode

JavaScript expose deux fonctions globales intégrées pour Base64 : btoa() (binary-to-ASCII, encoder) et atob() (ASCII-to-binary, décoder). Les deux sont des API legacy de l'ère Netscape et ont une limitation célèbre : elles ne fonctionnent que sur des chaînes d'octets Latin-1. Appeler btoa('é') lance InvalidCharacterError parce que la chaîne JavaScript 'é' contient un point de code au-dessus de U+00FF qui ne tient pas dans un seul octet. La correction moderne est d'encoder d'abord en octets UTF-8 via TextEncoder, puis convertir le Uint8Array résultant en une chaîne Latin-1 pour la consommation par btoa(). Le motif : btoa(String.fromCharCode(...new TextEncoder().encode(str))). Décodage à l'envers : new TextDecoder().decode(Uint8Array.from(atob(str), c => c.charCodeAt(0))). Les navigateurs plus récents exposent Uint8Array.toBase64() et Uint8Array.fromBase64() comme méthodes intégrées, mais l'adoption se déploie encore en 2026, le polyfill via btoa/atob reste le défaut cross-browser. Pour les fichiers spécifiquement, FileReader.readAsDataURL() est le chemin le plus simple : déposez un fichier dans un input, le reader renvoie une chaîne data:mime/type;base64,... avec tout correctement encodé ; enlevez le préfixe data: pour obtenir juste la portion Base64.

Portée honnête : ce que cet outil fait et ne fait pas

Cet outil encode du texte ou des fichiers (jusqu'à 5 Mo) en Base64 et décode des chaînes Base64 en texte ou fichiers téléchargeables. Il utilise l'alphabet standard RFC 4648 (avec + et /) par défaut ; Base64URL URL-safe (avec - et _) est une option future. Le texte UTF-8 est géré correctement via TextEncoder, le piège btoa-Latin-1 est corrigé. La limite de 5 Mo existe parce que Base64 étend les données de 33 % et la chaîne encodée vit entièrement en mémoire navigateur ; un fichier binaire de 5 Mo produit ~6,7 Mo de texte Base64 plus le buffer original, ce qui fonctionne sur tout appareil moderne. Pour des fichiers plus grands, les alternatives standard sont la ligne de commande base64 sur macOS/Linux (base64 -i input.bin -o output.txt), le module base64 de Python, ou Buffer.from(data).toString('base64') de Node.js. Cet outil ne gère pas : Base64 en streaming (encodage fichier-par-fragment pour des fichiers plus grands que la mémoire) ; la variante URL-safe dans cette version (prévu) ; ni l'encodage quoted-printable MIME (un schéma RFC 2045 différent pour le contenu texte d'e-mail).

Confidentialité : pourquoi le tout-navigateur compte

Base64 n'est pas du chiffrement, mais les données encodées sont souvent sensibles : clés d'API que vous incorporez dans un fichier de config, certificats que vous encodez pour le transport, captures d'écran internes que vous incorporez comme URI data dans la documentation, ou reçus PDF que vous encodez pour un client. Les encodeurs côté serveur voient votre entrée. Cet outil tourne entièrement dans votre navigateur via JavaScript, vérifiez dans l'onglet Network de DevTools en cliquant Encode, ou mettez la page hors ligne (mode avion) après chargement et l'outil fonctionne toujours. Sûr pour encoder des identifiants d'API, des captures avec PII, des documents internes ou toute donnée que vous ne voulez pas voir copiée sur le disque dur d'un inconnu.

Questions fréquentes

Base64 est-il sécurisé ?

Non. Base64 est un encodage, pas un chiffrement. N'importe qui peut décoder une chaîne Base64. N'utilisez jamais Base64 pour protéger des données sensibles : utilisez un véritable chiffrement (AES, RSA) pour la sécurité.

Pourquoi Base64 augmente-t-il la taille des fichiers ?

L'encodage Base64 augmente la taille des données d'environ 33 %. Trois octets de données binaires deviennent quatre caractères Base64. Ce surcoût est le prix à payer pour pouvoir transmettre des données binaires sous forme de texte.

Puis-je encoder des fichiers ?

Oui ! Glissez-déposez n'importe quel fichier sur l'encodeur, ou cliquez pour parcourir. Le fichier sera converti en Data URI Base64 que vous pourrez coller directement dans du HTML, du CSS ou du JavaScript.

Quelle est la différence entre Base64 et Base64URL ?

Deux caractères. Base64 standard (RFC 4648 §4) utilise + et / comme 62e et 63e caractères de l'alphabet. Base64URL URL-safe (RFC 4648 §5) utilise - et _ à la place, pour que la chaîne encodée se glisse directement dans les URL sans percent-encoding. JWT, OAuth, WebAuthn et la plupart des API web modernes utilisent Base64URL. Cet outil émet actuellement du Base64 standard ; URL-safe est sur la liste des fonctionnalités futures. Pour convertir standard en URL-safe à la main : remplacer + par -, / par _, optionnellement enlever le = final de remplissage.

Pourquoi mon texte Unicode échoue dans certains outils Base64 ?

Parce que la fonction legacy btoa() de JavaScript ne fonctionne que sur des chaînes d'octets Latin-1, appeler btoa('é') lance InvalidCharacterError. Beaucoup d'anciens encodeurs basés sur le navigateur utilisent btoa directement sans l'étape de conversion UTF-8, donc toute entrée non-ASCII casse. Le code moderne (et cet outil) encode les chaînes via TextEncoder d'abord, produisant une séquence d'octets UTF-8 que btoa peut alors encoder sans risque. La méthode intégrée plus récente Uint8Array.toBase64() gère UTF-8 nativement mais n'est pas encore baseline sur tous les navigateurs.

Mes données sont-elles téléversées ?

Non. L'encodage et le décodage tournent entièrement dans votre navigateur via JavaScript. Texte et fichiers ne traversent jamais le réseau, vérifiez dans l'onglet Network de DevTools en cliquant Encode, ou mettez la page hors ligne (mode avion) après chargement et l'outil fonctionne toujours. Sûr pour identifiants d'API, captures d'écran porteuses de PII, fichiers de config internes ou toute donnée que vous ne voulez pas voir copiée sur le disque dur d'un inconnu.

Outils associés