Encodeur et décodeur Base64

Base64 transforme n’importe quelle suite d’octets en un texte composé de 64 caractères sans risque, ce qui permet à des données binaires ou non ASCII de traverser des systèmes qui ne comprennent que l’ASCII brut : corps d’e-mails, chaînes JSON, en-têtes HTTP, fichiers de configuration. Cet outil encode et décode du texte dans les deux sens, et le fait correctement pour tous les caractères Unicode, ce que les fonctions natives btoa et atob du navigateur ne savent pas faire.

Comment ça marche

En mode Encoder, votre texte est d’abord converti en octets UTF-8 avec TextEncoder, puis ces octets sont encodés en Base64 par blocs de 32 Ko, pour que les entrées très longues ne fassent pas déborder la pile d’appels. La sortie utilise l’alphabet standard (A–Z, a–z, 0–9, +, /) avec le remplissage =, tel que le définit la section 4 de la RFC 4648.

En mode Décoder, le Base64 est reconverti en octets avec atob, puis décodé en UTF-8 en mode strict. Deux erreurs distinctes peuvent apparaître :

• Ceci ne ressemble pas à du Base64 valide signifie que l’entrée contient des caractères hors de l’alphabet, ou que sa longueur est impossible. Les espaces et les retours à la ligne sont tolérés, l’absence de remplissage est pardonnée, mais pas la variante URL-safe avec - et _ : remplacez d’abord ces caractères par + et /.
• Les données décodées ne sont pas du texte UTF-8 valide signifie que le Base64 était correct, mais que les octets ne forment pas du texte. C’est ce que vous obtenez en décodant une image, un certificat au format DER ou un blob compressé. L’outil se limite volontairement au texte : il ne vous proposera pas un rendu déformé de données binaires.

Tout s’exécute localement, et le résultat se met à jour à chaque frappe.

Ce que Base64 est, et ce qu’il n’est pas

Base64 est un encodage, pas un chiffrement. N’importe qui peut l’inverser en une fraction de seconde, et il n’offre pas non plus la moindre protection de l’intégrité. Si vous tombez sur des identifiants « protégés » par du Base64, considérez-les comme du texte en clair. L’en-tête d’authentification HTTP Basic en est l’exemple classique : Basic dXNlcjpwYXNz, c’est tout simplement user:pass.

Ce n’est pas non plus un format compact. Chaque groupe de 3 octets devient 4 caractères : la sortie est donc environ 33 % plus volumineuse que l’entrée, sans compter le remplissage. Embarquer ainsi de gros fichiers dans du JSON ou du HTML coûte de la bande passante ; au-delà de quelques kilo-octets, préférez une requête binaire séparée.

Le remplissage = ne porte aucune donnée. Certaines implémentations l’omettent, et la RFC 7515 (JSON Web Signatures) impose de l’omettre dans la forme URL-safe utilisée par les JWT. Voilà pourquoi un segment de JWT collé ici demande une petite retouche avant de pouvoir être décodé ; le décodeur JWT gère cette variante à votre place.

Équivalent en ligne de commande

Les mêmes opérations sous Linux et macOS, avec -n pour empêcher echo d’ajouter un saut de ligne qui se retrouverait dans l’encodage :

echo -n 'héllo wörld' | base64          # aMOpbGxvIHfDtnJsZA==
echo 'aMOpbGxvIHfDtnJsZA==' | base64 -d  # héllo wörld

Dans ses anciennes versions, l’utilitaire base64 de macOS décode avec -D ; --decode fonctionne sur les deux systèmes.

Pour aller plus loin

Base64 apparaît partout où un protocole doit transporter des octets dans du texte. Le guide sur la conception d’API REST explique quand embarquer des données binaires dans un corps JSON et quand plutôt y faire référence par un lien, et celui consacré à OAuth 2.0 détaille l’en-tête utilisé par le flux client credentials et l’encodage URL-safe qu’utilisent les jetons. Pour l’encodage-pourcent, l’autre mécanisme qui rend un texte sûr dans une URL, consultez l’encodeur d’URL.