Encodeur et décodeur Base64

Qu’est-ce qu’un encodeur et décodeur base64 ?

Le base64 n’est pas un format de fichier ni un protocole, c’est un plan de correspondance : n’importe quelle suite d’octets se réécrit en une chaîne composée uniquement des 64 caractères A-Z, a-z, 0-9, + et /, plus = pour le remplissage. L’intérêt, c’est que cette chaîne passe sans encombre partout où seul du texte ASCII est toléré : un en-tête HTTP, un attribut JSON, une pièce jointe d’e-mail, la charge d’un JWT. On l’utilise pour transporter des données binaires — une image, une clé, un fichier — à travers des canaux qui ne comprennent que du texte, jamais pour cacher quoi que ce soit.

Cet outil encode du texte en base64 et décode du base64 vers du texte, avec les deux alphabets qu’on croise en pratique (standard et compatible URL) et une option pour couper les lignes tous les 76 caractères côté encodage. Le vrai piège n’est pas dans le principe — il est dans ce qui se passe entre le texte et les octets, avant même que l’encodage commence, et c’est précisément là que le raccourci natif du navigateur trébuche.

Comment ça marche

1. Choisissez le sens et l’alphabet. Encoder ou Décoder, puis Standard (+ / =) ou Compatible URL (- _) selon d’où vient votre base64 — un JWT, par exemple, utilise systématiquement l’alphabet compatible URL. En mode encodage, cochez Couper les lignes tous les 76 caractères si la sortie doit respecter la convention MIME du courrier électronique.
2. Collez votre contenu. Le champ de saisie s’appelle Texte en encodage et Base64 en décodage. Le résultat se met à jour à chaque frappe ; si ce que vous collez à décoder n’est pas du base64 valide, ou ne redonne pas du texte UTF-8, l’erreur remplace directement la sortie plutôt que de l’afficher tronquée ou corrompue.
3. Lisez le résultat et copiez-le. La ligne sous la sortie détaille les caractères en entrée, les octets en entrée et les caractères en sortie — trois nombres rarement identiques. Le bouton Copier bascule sur Copié ! pendant deux secondes une fois cliqué.

Pourquoi le raccourci d’une ligne avec btoa est faux

Le réflexe, en JavaScript, c’est btoa(texte). Ça marche pour de l’anglais pur ASCII et ça casse dès qu’un accent apparaît — mais pas de la façon dont on l’attendrait. btoa("café") renvoie Y2Fm6Q==. La bonne réponse en UTF-8 est Y2Fmw6k=. Aucune erreur, aucun avertissement : btoa a pris le é pour l’octet unique e9 (son code Latin-1) au lieu des deux octets c3 a9 que l’UTF-8 exige réellement. Redonnez Y2Fm6Q== à n’importe quel décodeur qui attend de l’UTF-8 et vous récupérez caf suivi d’un caractère de remplacement — le é a disparu, sans trace de l’erreur nulle part dans la chaîne. Pour du texte français, c’est le quotidien : é, è, à, ç tombent tous dans ce premier piège, le silencieux, celui qu’on ne voit qu’une fois en production.

Au-dessus de U+00FF, btoa change de comportement et lève carrément une exception : btoa("👍"), btoa("€") et btoa("日本語") déclenchent tous une InvalidCharacterError. Le symbole euro fait planter le raccourci pendant que le é le corrompt sans un mot — deux échecs différents pour le même bug de fond, qui est de traiter les caractères comme des octets alors que l’UTF-8 en utilise plusieurs par caractère dès qu’on sort de l’ASCII.

Cet outil convertit d’abord le texte en octets UTF-8, puis encode ces octets — donc tout fait l’aller-retour intact, accents et emojis compris. Vérifié : « café » (5 octets) donne Y2Fmw6k= ; « 👍 » (4 octets) donne 8J+RjQ== ; « 日本語 » (9 octets) donne 5pel5pys6Kqe ; « مرحبا » (10 octets) donne 2YXYsdit2KjYpw==. C’est aussi pour ça que la ligne de comptage distingue caractères et octets : « café » fait 4 caractères mais 5 octets, et « 👍 » est un seul caractère pour 4 octets — sachant que le .length de JavaScript, lui, en annonce 2, parce qu’il compte des unités UTF-16, un troisième système de mesure encore différent.

Le base64 lui-même fait toujours 3 octets vers 4 caractères, une expansion exacte de 4/3, environ 33 % de plus, arrondie au multiple de 4 supérieur avec du remplissage =. Mesuré : 100 octets deviennent 136 caractères, 3 000 octets deviennent 4 000. L’alphabet compatible URL remplace + par - et / par _, et omet en général le = de remplissage — c’est la variante que produisent les JSON Web Tokens. Les mêmes trois octets donnent +/++ en standard et -_-- en compatible URL : rien ne change dans les données, seuls les deux caractères ambigus dans une URL sont remplacés.

Ce que cet outil ne fait pas

C’est un outil de texte, pas un convertisseur de fichiers. Au décodage, les octets obtenus passent par un décodeur UTF-8 strict : collez le base64 d’un PNG ou d’un ZIP et l’outil vous dira que ces octets ne sont pas du texte, plutôt que d’afficher un résultat inutilisable ou de planter en silence.

Le base64 est un encodage, pas un chiffrement — n’importe qui l’inverse en une seconde, sans clé, sans mot de passe. Il ne cache rien ; il existe uniquement pour faire transiter des octets dans des canaux qui n’acceptent que du texte. Ne l’utilisez jamais pour protéger un secret.

Rien de ce que vous collez ici n’est envoyé où que ce soit, et c’est précisément pour ça qu’un outil qui tourne dans le navigateur a du sens pour tout ce qui est sensible : coller un token ou les données d’un client dans un encodeur hébergé côté serveur revient à les transmettre à ce serveur. Fermez l’onglet ou rechargez la page, et tout disparaît — rien n’est conservé.

Pourquoi c’est gratuit ?

Encoder ou décoder du base64 est un calcul trivial pour un navigateur — quelques lignes de JavaScript, exécutées localement, sans appel réseau. Faire payer ça n’aurait aucun sens. Comme le reste des outils de FreeToGenerate.com, celui-ci reste gratuit, sans compte, sans limite d’utilisation et sans filigrane sur le résultat.