Encodage / décodage Base64

Qu’est-ce que Base64 ?#

Base64 est une façon d’écrire des octets arbitraires en n’utilisant que 64 caractères ASCII imprimables (A-Z, a-z, 0-9, +, /, avec = pour le remplissage). Il existe parce qu’une grande partie du monde informatique a été conçue pour le texte — corps d’e-mail, champs JSON, en-têtes HTTP, préfixes d’URI de données — et qu’elle bloque sur les octets bruts, surtout ceux avec le bit de poids fort à 1 ou des codes de contrôle intégrés. Base64 est la langue véhiculaire que vous saisissez quand vous avez besoin que des données binaires survivent à un canal textuel uniquement.

Chaque trois octets d’entrée (24 bits) devient quatre caractères base64 (chacun codant 6 bits). C’est pourquoi la sortie base64 est toujours un multiple de quatre caractères de long, et pourquoi elle fait environ 33 % de plus que les octets d’origine — la redondance est le prix de l’imprimabilité. Quand la longueur d’entrée n’est pas un multiple de trois, un ou deux caractères de remplissage = apparaissent à la fin.

Cette page encode et décode le base64 de façon sûre avec UTF-8. Un piège dans lequel tout le monde tombe : passer une chaîne directement à btoa() lève InvalidCharacterError dès qu’elle contient un caractère non ASCII (é, 中文, un emoji). La solution consiste à encoder d’abord le texte en octets UTF-8, puis en base64 — c’est exactement ce que fait cet outil, donc café fait un aller-retour correct au lieu de lever une erreur.

Mode d’emploi#

1. Choisissez le sens avec le commutateur Encoder / Décoder en haut à gauche de la barre d’outils.
2. Saisissez ou collez votre texte dans le panneau Entrée à gauche.
   • En mode Encoder, l’entrée est traitée comme du texte UTF-8.
   • En mode Décoder, l’entrée doit être une chaîne base64. Les espaces sont tolérés.
3. Cochez URL-safe si vous avez besoin de l’alphabet base64url (- et _ à la place de + et /, remplissage supprimé). C’est ce qu’attendent les JWT et de nombreux schémas d’URL signées.
4. Le résultat apparaît en direct dans le panneau Sortie à droite. Cliquez sur Copier pour le récupérer.
5. Utilisez Exemple pour déposer une paire de démonstration, et Effacer pour réinitialiser les deux panneaux.

Principales fonctionnalités#

• Sûr pour UTF-8 dans les deux sens. L’encodage fait passer le texte par TextEncoder d’abord, donc les caractères multioctets ne plantent jamais ; le décodage fait passer les octets par TextDecoder, donc le texte d’origine est restitué exactement.
• Alphabets standard et URL-safe. Une case à cocher bascule entre le base64 classique (+/=) et le base64url (-_ sans remplissage), avec un remplissage correct au décodage.
• Entièrement côté client. La conversion s’exécute uniquement dans votre navigateur — il n’y a aucun backend et aucune requête réseau. Coller un jeton sensible ici ne l’envoie nulle part.
• Ligne d’état en direct. La barre sous les panneaux signale les erreurs d’encodage/décodage (par exemple une entrée tronquée ou en forme de %) au lieu de produire silencieusement des déchets.

Exemple détaillé#

Avec Encoder et le mode standard (pas URL-safe), le texte ASCII Hello, World! devient :

SGVsbG8sIFdvcmxkIQ==

Les deux = finaux montrent que l’entrée de 13 octets n’était pas un multiple de trois — c’est attendu, pas une erreur.

La gestion UTF-8 compte dès que vous quittez l’ASCII. Encoder café (où é vaut deux octets UTF-8, c3 a9) donne :

Y2Fmw6k=

Si vous aviez appelé btoa("café") directement dans une console, cela aurait levé une erreur. Cet outil non, parce qu’il encode d’abord les octets UTF-8.

Le mode URL-safe réécrit l’alphabet afin que la sortie ne porte jamais de caractères qu’une URL interpréterait mal : + devient -, / devient _, et le remplissage = final est retiré (rajouté automatiquement au décodage). Prenez la sortie standard ci-dessus, SGVsbG8sIFdvcmxkIQ== — en mode URL-safe les deux = de remplissage sont retirés, donnant SGVsbG8sIFdvcmxkIQ. La permutation +// → -/_ ne change quelque chose que quand ces caractères apparaissent effectivement dans la sortie, ce qui tend à se produire avec des charges utiles binaires comme les condensats de hachage ou les jetons aléatoires — précisément le type de données que vous glissez dans un chemin d’URL ou un paramètre de requête sans échappement supplémentaire.

FAQ#

Mon texte décodé s’affiche en Mojibake. Que s’est-il passé ?#

Presque toujours, le base64 que vous avez décodé était l’encodage d’octets dans un autre jeu de caractères (souvent Latin-1 ou Windows-1252), pas UTF-8. Cet outil décode les octets en UTF-8, donc un é encodé en Latin-1 (0xe9, un octet isolé) n’est pas de l’UTF-8 valide et s’affiche mal. Découvrez comment l’autre bout a encodé le texte d’origine, ou réencodez-le d’abord en UTF-8.

Base64 standard ou base64url — lequel choisir ?#

Le standard (+/=) est le défaut pour tout ce qui ne va pas dans une URL : pièces jointes d’e-mail, URI data:, champs JSON portant du binaire. Activez URL-safe quand la sortie va se trouver dans un chemin d’URL, une chaîne de requête, ou un segment de JWT, où +, / et = cassent l’analyse ou sont altérés par le transport. Le décodage de l’une ou l’autre forme est accepté automatiquement.

Pourquoi la sortie encodée est-elle plus longue que mon entrée ?#

C’est inhérent, pas un bug. Base64 tasse 6 bits par caractère au lieu de 8, donc la sortie fait environ 4/3 de la taille d’entrée — soit environ 33 % de surcoût. Pour de très petites entrées, elle peut paraître encore plus grande relativement à l’original, parce que la structure fixe domine.

Cet outil peut-il déchiffrer ou casser une chaîne base64 ?#

Non — base64 est un encodage, pas un chiffrement. Il est pleinement réversible par conception et ne porte aucune clé. N’importe qui dispose de la chaîne peut la décoder. Si vous avez réellement besoin de secret, chiffrez d’abord (par exemple avec un schéma de chiffrement authentifié) puis encodez en base64 le texte chiffré pour le transport.