Guide de l’encodeur et du décodeur Base64 : UTF-8, Base64url et erreurs

Comment encoder ou décoder du texte

Ouvrez l’encodeur et le décodeur Base64, puis collez du texte ou une chaîne encodée. Laissez l’option « Base64 compatible URL (sans remplissage à l’encodage) » désactivée pour utiliser l’alphabet standard, ou activez-la lorsque le format destinataire exige Base64url. Encoder convertit toute l’entrée en Base64 ; Décoder la reconvertit en texte UTF-8. La saisie seule ne lance pas de conversion.

Lisez le résultat avant de choisir Copier le résultat ou Télécharger. Utiliser le résultat comme entrée remplace le contenu de l’éditeur par un résultat qui respecte la limite d’entrée ; vous pouvez ensuite choisir l’action inverse pour vérifier l’aller-retour. Modifier l’entrée ou les options de conversion invalide l’ancien résultat. Retour à la ligne modifie la présentation visuelle, pas les caractères encodés ni les sauts de ligne du contenu.

• Commencez par un exemple connu comme foo et Zm9v avant d’examiner une valeur d’application.
• Choisissez l’alphabet exigé par votre application ; les lettres et les chiffres communs ne suffisent pas toujours à reconnaître la variante utilisée.
• Conservez l’original si chaque octet doit être préservé. L’importation de texte, l’encodage des caractères et des fins de ligne supplémentaires peuvent modifier ce que vous encodez.

Ce que Base64 fait aux octets

Base64 divise chaque groupe de trois octets en quatre valeurs de six bits, puis associe ces valeurs à des caractères de son alphabet. Un dernier groupe incomplet demande un traitement particulier et peut nécessiter un remplissage. Les lettres visibles représentent les octets d’entrée ; elles ne constituent ni une nouvelle langue ni une clé secrète.

Ces exemples avec l’alphabet standard comprennent la chaîne vide et des terminaisons ASCII d’un, deux et trois octets. Les espaces et les sauts de ligne du texte que vous encodez sont de véritables octets et changent le résultat. Décoder le même encodage canonique restitue le texte UTF-8 d’origine, y compris ces caractères.

RFC 4648 : Base64, Base64url, remplissage et encodage canonique

Base64 standard et Base64url

Les deux variantes utilisent des lettres et des chiffres. Base64 standard emploie + et / pour les deux derniers symboles de l’alphabet ; Base64url emploie - et _. ToolMellow ajoute les = finaux nécessaires en mode standard et les omet en mode sûr pour les URL. Par exemple, l’emoji ci-dessus devient 8J-YgA dans ce dernier mode.

Le décodeur accepte uniquement l’alphabet sélectionné. Les deux modes acceptent une entrée sans remplissage ou avec un remplissage facultatif correctement placé. Base64url n’interdit pas universellement le remplissage : le protocole qui l’utilise décide s’il est obligatoire, autorisé ou omis. Choisissez le format requis au lieu de supposer que toutes les URL ou tous les jetons suivent la même convention.

RFC 4648 : Base64, Base64url, remplissage et encodage canonique

Unicode, emojis et décodage UTF-8

Le texte passe par UTF-8 ; les accents, le chinois, l’arabe et les emojis peuvent donc être conservés lors d’un aller-retour si l’entrée est un texte Unicode bien formé. La longueur d’une chaîne JavaScript compte les unités de code UTF-16 ; sa longueur en octets UTF-8 est différente. L’emoji 😀 occupe deux unités UTF-16, mais quatre octets UTF-8, qui produisent huit caractères Base64 avec remplissage.

L’encodage rejette un substitut Unicode isolé. Le décodage rejette l’UTF-8 invalide au lieu de remplacer silencieusement les octets incorrects. Un BOM UTF-8 encodé en tête est conservé comme U+FEFF dans la chaîne décodée ; il peut être invisible dans l’éditeur. Un texte valide peut également contenir des caractères de contrôle ou différentes formes de normalisation Unicode. Base64 ne normalise pas le texte et ne rend pas son exécution sûre.

RFC 3629 : encodage des caractères UTF-8WHATWG Encoding : TextEncoder, TextDecoder et gestion du BOMECMAScript : longueur des chaînes et isWellFormed

Remplissage, espaces blancs et bits inutilisés canoniques

Le remplissage comporte au plus deux caractères = finaux, et la longueur avec remplissage doit être divisible par quatre. Le décodeur autorise aussi une entrée sans remplissage dont la terminaison est valide, mais une longueur restante d’un caractère ne peut pas représenter un octet complet. Zg== et Zg donnent tous deux f ; Zg= est mal formé. Une entrée vide donne un résultat vide valide.

Avant le décodage, ToolMellow supprime uniquement TAB, LF, CR et SPACE. Il rejette le saut de page, la tabulation verticale, l’espace insécable et les autres espaces blancs Unicode. La limite de l’entrée d’origine est vérifiée avant cette suppression. Ce comportement est donc plus restrictif qu’une promesse générale d’ignorer tous les espaces blancs.

Dans cet outil, les bits inutilisés du dernier symbole de l’alphabet doivent être nuls. Le décodeur vérifie que le réencodage des octets décodés correspond à l’entrée normalisée sans remplissage. Zh== est rejeté, même si un décodeur permissif pourrait produire le même octet qu’avec la forme canonique Zg==. RFC 4648 autorise ce rejet plus strict ; l’acceptation par un autre décodeur ne prouve pas que l’entrée est canonique.

RFC 4648 : Base64, Base64url, remplissage et encodage canoniqueWHATWG Infra : décodage Base64 permissifWHATWG HTML : atob et btoa

De combien Base64 augmente la taille et quelles sont les limites

Pour n octets d’entrée, la longueur de Base64 avec remplissage est de 4 × ceil(n / 3) caractères. Zéro octet produit zéro caractère ; un octet en produit quatre, deux en produisent quatre et trois en produisent quatre. Le surcoût tend vers un tiers pour les grandes entrées, mais il n’est pas exactement de 33% pour chaque valeur. La sortie sûre pour les URL sans remplissage retire le ou les deux derniers caractères de remplissage, selon le cas.

Comptez les octets UTF-8 pour la formule de taille et les unités de code UTF-16 pour la limite de l’éditeur. L’outil accepte jusqu’à 1,000,000 unités de code en entrée, avant de supprimer les espaces blancs lors du décodage. La sortie n’est pas soumise au même plafond : un million d’octets ASCII produisent 1,333,336 caractères avec remplissage. Copier et Télécharger restent disponibles, mais Utiliser le résultat comme entrée ne peut pas charger un résultat dépassant la limite d’entrée.

RFC 4648 : Base64, Base64url, remplissage et encodage canoniqueWHATWG Encoding : TextEncoder, TextDecoder et gestion du BOMECMAScript : longueur des chaînes et isWellFormed

Ouvrir un fichier texte n’encode pas ses octets binaires bruts

Le sélecteur de fichiers lit un fichier local comme texte UTF-8 au moyen de File.text(). Un fichier de 4,000,000 octets ou plus est rejeté ; un texte de plus de 1,000,000 unités UTF-16 est également rejeté après lecture. L’application ne téléverse pas le fichier pour effectuer cette conversion. L’extension du nom ne prouve pas que ses octets sont du texte UTF-8.

La lecture ordinaire d’un fichier comme texte supprime un BOM UTF-8 initial et remplace les séquences UTF-8 mal formées. Cela peut modifier les octets d’origine avant l’encodage. Ce comportement diffère du décodeur Base64, qui rejette l’UTF-8 mal formé et conserve U+FEFF lors du décodage. Pour des images, des PDF, des octets arbitraires ou une récupération exacte des octets d’un fichier, utilisez l’outil distinct Base64 vers fichier lorsque cela convient ; cet espace de texte n’est pas un encodeur de fichiers binaires bruts.

API File du W3C : lecture d’un Blob comme texteWHATWG Encoding : TextEncoder, TextDecoder et gestion du BOM

Pourquoi mon Base64 est-il invalide ?

Commencez par identifier le format attendu et vérifiez si la valeur est censée produire du texte au décodage. Retirez volontairement la syntaxe d’application qui entoure la valeur, plutôt que de supprimer des caractères inconnus jusqu’à ce que la conversion fonctionne. Ce décodeur n’extrait pas automatiquement les charges utiles d’URL de données, les segments de jetons, les chaînes JSON entre guillemets ou le HTML. Ces enveloppes ont leurs propres règles d’analyse et de validation.

Si l’alphabet et la structure sont valides, mais que les octets décodés ne sont pas de l’UTF-8, les données peuvent être un fichier binaire ou utiliser un autre encodage de caractères. Il s’agit d’une erreur liée au périmètre textuel de l’outil, pas d’une preuve que les octets Base64 sont corrompus. Si l’accès au presse-papiers est indisponible, sélectionnez le résultat et copiez-le manuellement. Un navigateur non pris en charge ou un worker bloqué peut aussi empêcher la conversion ; utilisez un navigateur récent pris en charge et lisez le message d’erreur affiché.

RFC 4648 : Base64, Base64url, remplissage et encodage canoniqueRFC 3629 : encodage des caractères UTF-8

Base64url, encodage pourcent et URL de données

Base64url et l’encodage pourcent répondent à des besoins différents. L’encodage pourcent représente certains octets d’URL par des séquences avec % ; Base64url représente une séquence entière d’octets avec son propre alphabet. Un signe plus devient un espace précisément lors de l’analyse d’application/x-www-form-urlencoded, pas dans toutes les URL. Utilisez l’encodeur et le décodeur d’URL pour cette tâche distincte.

Une URL de données comporte le schéma data:, un type de média facultatif et une virgule avant sa charge utile, avec un marqueur Base64 lorsqu’il s’applique. Coller toute cette enveloppe dans le décodeur de texte fait échouer la vérification de l’alphabet. Extrayez la charge utile voulue avec l’outil adapté et déterminez s’il s’agit de texte ou de données binaires. Base64 ne rend pas un script intégré, un document ou un fichier téléchargé digne de confiance.

WHATWG URL : analyse des formulaires encodés pour les URLRFC 2397 : schéma des URL de données

Les segments JWT et HTTP Basic sont des données de protocole

Un JWS compact utilise trois segments séparés par des points ; un JWE compact en utilise cinq. Décoder un segment textuel d’un JWT peut révéler du JSON, mais ne vérifie pas une signature, ne déchiffre pas un contenu chiffré, ne valide pas l’expiration et n’accorde aucune autorisation. Un segment de signature peut contenir des octets arbitraires et ne pas être décodable en UTF-8. Suivez le protocole réel du jeton et utilisez une bibliothèque de vérification maintenue dans votre application.

Les identifiants HTTP Basic utilisent une représentation Base64 d’une séquence nom d’utilisateur/mot de passe, avec des règles d’encodage de caractères propres au protocole. Base64 n’apporte aucune confidentialité. Cet outil de texte UTF-8 ne prouve pas que des identifiants correspondent à l’interprétation de tous les serveurs. Ne publiez pas de véritables identifiants dans les exemples et utilisez le transport sécurisé et la procédure d’authentification requis.

RFC 7515 : sérialisation compacte de JSON Web SignatureRFC 7516 : sérialisation compacte de JSON Web EncryptionRFC 7617 : authentification HTTP Basic

Base64 n’est ni un chiffrement, ni un hachage, ni une compression

Toute personne disposant d’une valeur Base64 peut inverser sa représentation sans clé secrète. Le chiffrement exige une construction cryptographique et une gestion des clés ; un hachage produit une empreinte avec des objectifs et des propriétés différents. Convertir un mot de passe en Base64 n’est pas un stockage adapté des mots de passe. L’outil de hachage distinct produit des empreintes ; ce n’est ni un système de stockage des mots de passe ni un substitut au chiffrement.

Base64 augmente également la taille des octets au lieu de les compresser. Il peut transporter des octets chiffrés, compressés ou signés, mais ne crée pas lui-même ces protections. Déterminez les besoins de votre application avant d’ajouter une couche d’encodage et gardez les secrets hors des exemples partagés, captures d’écran et résultats téléchargés.

RFC 4648 : Base64, Base64url, remplissage et encodage canonique

Copier, télécharger, vérifier l’aller-retour et effacer

Télécharger enregistre le résultat comme texte UTF-8 dans toolmellow-result.txt. Ce fichier n’est ni une reconstruction binaire ni un rapport de conversion. Un résultat vide valide active aussi Copier le résultat et Télécharger. Pour une vérification simple, encodez un texte connu, utilisez le résultat comme entrée s’il tient dans la limite, puis décodez-le avec l’alphabet correspondant et comparez-le au texte d’origine.

Effacer supprime l’entrée, le résultat, les erreurs, le contenu de recherche/remplacement et l’historique de l’éditeur, tout en conservant les choix de Base64 sûr pour les URL et de Retour à la ligne. Actualiser ou fermer l’espace de travail abandonne les données de travail en mémoire ; les fichiers déjà téléchargés restent sur votre appareil. Effacer ne garantit pas une suppression forensique dans la mémoire du navigateur ou du système d’exploitation.

Ce que signifie le traitement local et quelles sont ses limites

La conversion s’exécute dans un worker du navigateur. L’application n’envoie pas à un serveur de conversion le texte collé, le contenu des fichiers sélectionnés ni les résultats. L’entrée de travail reste dans la page actuelle au lieu d’être enregistrée dans l’historique d’un compte. Consultez la page de confidentialité du site pour connaître les détails du stockage et des transferts temporaires.

Charger le site web entraîne malgré tout des requêtes réseau. L’infrastructure d’hébergement reçoit les métadonnées ordinaires de connexion et de requête, et le site public utilise Google Analytics pour les visites de pages, avec des cookies et des informations sur le navigateur et l’appareil. La conversion locale n’implique pas l’anonymat ni une promesse d’absence de trafic réseau ou de journaux d’infrastructure. Les fichiers téléchargés et un résultat copié manuellement peuvent quitter l’espace de travail par vos propres actions.

Intégrer l’outil Base64 en conservant son lien d’attribution

Ouvrez la section d’intégration sous l’espace de travail, choisissez la langue de la page, puis copiez ou téléchargez l’extrait HTML fourni. Collez-le dans une zone HTML qui autorise les iframes et les scripts externes. L’extrait comprend l’iframe ToolMellow, son script d’ajustement de taille et un lien visible vers la page de l’outil ToolMellow dans la langue correspondante. Conservez ce lien d’attribution.

Prévisualisez l’intégration et vérifiez les écrans étroits. Elle conserve le même périmètre textuel et les mêmes limites d’entrée ; ce n’est ni une API de conversion distante ni un encodeur de fichiers binaires. L’accès au presse-papiers dépend des autorisations du navigateur, et votre plateforme doit accepter les ressources externes. Le lien fourni utilise nofollow et noopener ; sa présence ne garantit pas une amélioration du classement dans les moteurs de recherche.

Questions fréquentes

Sources et lectures complémentaires

• RFC 4648 : Base64, Base64url, remplissage et encodage canonique
• RFC 3629 : encodage des caractères UTF-8
• WHATWG Encoding : TextEncoder, TextDecoder et gestion du BOM
• ECMAScript : longueur des chaînes et isWellFormed
• WHATWG Infra : décodage Base64 permissif
• WHATWG HTML : atob et btoa
• API File du W3C : lecture d’un Blob comme texte
• WHATWG URL : analyse des formulaires encodés pour les URL
• RFC 2397 : schéma des URL de données
• RFC 7515 : sérialisation compacte de JSON Web Signature
• RFC 7516 : sérialisation compacte de JSON Web Encryption
• RFC 7617 : authentification HTTP Basic