Encodeur et décodeur Base64 pour texte, images, Data URI et payload JWT
Encodez du texte UTF-8 et des images en Base64 dans le navigateur, puis décodez du Base64 en texte ou prévisualisez-le comme image. Le chinois, les emoji et les entrées multilignes fonctionnent, mais seul le Base64 standard est géré : les variantes URL-safe et les segments JWT bruts doivent être convertis, et les données binaires ressortent en UTF-8 illisible.
Ce que ce convertisseur Base64 gère — et ce qu'il ne gère pas
Texte UTF-8 dans les deux sens
La saisie est encodée aussitôt : TextEncoder convertit le texte en octets UTF-8 avant Base64, donc le chinois, le japonais et les emoji passent correctement, sans l'erreur que btoa brut lève sur les caractères non Latin-1.
Les images deviennent des Data URI
Passez en Image, choisissez un fichier : il est lu en data:image/...;base64,... . Recollez cette Data URI dans la zone Base64 pour l'afficher en ligne ; une source invalide montre un message de remplacement au lieu d'une image cassée.
Base64 standard uniquement, pas de mode URL-safe
Les caractères - et _ sont refusés : les payloads JWT et jetons URL-safe doivent d'abord être réécrits en + et /. Un padding = manquant est accepté, et espaces, tabulations et retours à la ligne sont ignorés.
Le décodage suppose de l'UTF-8
Le Base64 de données binaires est décodé comme du texte UTF-8, produisant des caractères de remplacement au lieu d'une erreur. Seul le texte UTF-8 fait un aller-retour propre ; les images et autres octets sont perdus.
Exécution locale, mais les très grosses entrées échouent
Rien n'est envoyé ; le texte est converti à chaque frappe. Aucune limite de taille n'est appliquée, et un texte très volumineux peut provoquer une erreur de pile d'appels car tous les octets sont étalés dans btoa d'un coup.
FAQ sur l'encodage et le décodage Base64
Le Base64 URL-safe (- et _) est-il pris en charge ?
Non. Seul l'alphabet + / fonctionne ; - ou _ lève InvalidCharacterError. Remplacez - par +, _ par /, puis complétez jusqu'à un multiple de 4 avant de coller ici.
Puis-je décoder un payload JWT ici ?
Seulement après conversion. Le segment de payload est du Base64 URL-safe sans padding, et cette page ne découpe pas le jeton et n'ajoute pas les caractères manquants. Collez un segment réécrit ; le résultat est du texte, pas du JSON analysé.
Puis-je convertir des fichiers en Base64 et inversement ?
Seulement des images, et dans un seul sens pour les fichiers : téléverser une image donne une Data URI. Aucun sélecteur de fichier texte, et le décodage ne produit jamais de fichier téléchargeable.
Pourquoi le chinois et les emoji passent-ils alors que btoa échoue d'habitude ?
Le code convertit le texte en octets UTF-8 avec TextEncoder avant btoa, puis le restaure avec TextDecoder. btoa appliqué directement à 中文 lève InvalidCharacterError ; ici non.
Que se passe-t-il avec du Base64 binaire (non UTF-8) ?
Il est décodé en UTF-8 : les octets arbitraires deviennent des caractères de remplacement, sans échec ni message. Pour conserver les octets, utilisez l'aperçu image ou un décodeur binaire dédié.
Y a-t-il une limite de taille, et mes données sont-elles envoyées ?
Rien n'est envoyé et il n'y a pas de limite ; la conversion est synchrone à chaque frappe. De très grosses entrées peuvent lever « Maximum call stack size exceeded », et plusieurs Mo peuvent figer l'onglet.
Comment sont traités le padding, les espaces et les entrées invalides ?
Un padding = manquant est accepté, et atob ignore espaces, tabulations et retours à la ligne. Une longueur % 4 == 1 ou un caractère hors alphabet lève InvalidCharacterError, sans message dans l'interface.
