Outil en ligne d'encodage et de décodage Base64

1. 1

   Choisissez un sens

   Prenez Encoder pour transformer du contenu en Base64, ou Décoder pour retrouver le texte ou le fichier d'origine à partir d'une chaîne Base64.

2. 2

   Fournissez l'entrée

   Saisissez ou collez dans le champ, ou déposez un fichier. L'encodage accepte tous les fichiers ; le décodage accepte les fichiers texte contenant du Base64, y compris les certificats PEM avec leurs lignes BEGIN et END.

3. 3

   Réglez le format

   Choisissez l'alphabet standard ou compatible URL, décidez de garder le remplissage, coupez à 64 ou 76 caractères, et activez l'option URI de données si le résultat part dans du HTML ou du CSS.

4. 4

   Vérifiez le résultat

   Le texte saisi se convertit au fil de la frappe. Le panneau indique la taille d'entrée, la taille de sortie et le surcoût, et au décodage il nomme l'alphabet détecté, l'encodage de texte utilisé et le type de fichier trouvé.

5. 5

   Copiez ou téléchargez

   Copiez le résultat dans le presse-papiers, téléchargez-le sous un nom correspondant à ce qu'il est vraiment, ou téléchargez un lot entier en un seul ZIP. Rien ne quitte votre appareil à aucun moment.

Neuf réglages, et chacun existe parce qu'un format réel en a besoin. Voici ce que change chacun et quand cela compte.

Alphabets standard et compatible URL

Base64 a besoin de soixante-quatre caractères imprimables. Cinquante-deux lettres et dix chiffres mènent à soixante-deux, et les deux derniers sont ceux sur lesquels les deux variantes divergent. L'alphabet standard de la RFC 4648 section 4 utilise le plus et la barre oblique, ce qui convient aux corps de messages et aux champs d'API. La variante compatible URL de la section 5 utilise le tiret et le tiret bas, car une barre oblique sépare les segments d'un chemin et un plus signifie espace dans une chaîne de requête. Tout le reste est identique, et c'est pourquoi une charge composée uniquement de lettres et de chiffres se décode de la même façon avec l'un ou l'autre.

Le remplissage, et quand le supprimer

Base64 travaille par groupes de trois octets, donc une charge dont la longueur n'est pas un multiple de trois se termine par un groupe incomplet. Les signes égal indiquent de combien. Le Base64 standard les garde ; le compatible URL généralement non, car un JSON Web Token met trois segments Base64 à la suite séparés par des points et le remplissage gênerait. Supprimer le remplissage ne perd rien : le décodeur déduit le nombre d'octets du dernier groupe de sa seule longueur, et c'est pourquoi cet outil rétablit le remplissage pour vous quand vous collez une chaîne qui n'en a pas.

Coupure des lignes pour PEM et MIME

Deux formats exigent des sauts de ligne à l'intérieur de la charge. PEM, défini par la RFC 7468, coupe à soixante-quatre caractères, et OpenSSL refusera un certificat arrivant sur une seule longue ligne. MIME, défini par la RFC 2045 section 6.8, impose des lignes d'au plus soixante-seize caractères dans un corps de message, en partie parce que les anciens transports inséraient leurs propres coupures et corrompaient la charge en le faisant. Ici, par défaut, il n'y a pas de coupure, car les deux autres grands usages du Base64 — une URI de données et un champ JSON — exigent une seule ligne continue, et un saut de ligne dans une URI de données l'empêche de se charger.

Encoder chaque ligne séparément

Parfois ce que vous avez n'est pas une charge mais une liste : une colonne de valeurs, un jeu d'identifiants, un enregistrement par ligne. Encoder tout le bloc donne une seule chaîne qu'il faudra décoder puis redécouper. Encoder chaque ligne séparément donne une valeur Base64 par ligne, prête à coller dans une colonne. Les fins de ligne Windows sont prises en compte : le retour chariot est traité comme faisant partie du saut et non comme le dernier caractère de la ligne, une différence que vous ne remarqueriez que plus tard, sous la forme d'un caractère invisible à la fin de chaque valeur décodée.

Validation stricte

La plupart du Base64 qui arrive entre les mains d'une personne a subi quelque chose : un client de messagerie qui a ajouté un guillemet, un document qui a transformé un tiret en tiret cadratin, un terminal qui a coupé une ligne. Le décodage indulgent ignore ce qui n'appartient pas à l'alphabet et rétablit le remplissage manquant, ce que l'on veut la plupart du temps. La validation stricte sert aux moments où vous devez savoir que la charge est exactement celle qui a été produite : elle refuse les caractères inconnus, refuse le remplissage au milieu et refuse un dernier caractère dont les bits restants ne sont pas nuls — le seul défaut autrement totalement invisible, puisque ces bits sont de toute façon écartés.

Encodages de texte en sortie

Le décodage donne des octets, et transformer des octets en texte lisible est une seconde décision que l'outil doit réussir. Lisez une charge Windows-1252 comme de l'UTF-8 et chaque guillemet typographique devient un caractère de remplacement ; lisez de l'UTF-16 comme de l'UTF-8 et vous obtenez un NUL entre chaque lettre. Sept encodages sont proposés avec une détection automatique qui lit d'abord une marque d'ordre des octets, puis teste les octets contre les règles de l'UTF-8, puis cherche le motif dense et unilatéral de NUL que seul l'UTF-16 produit, et seulement ensuite se rabat sur Windows-1252 — placé en dernier parce que c'est le seul des huit capable de décoder n'importe quelle suite d'octets, si bien que tout ce qui viendrait après n'aurait jamais son tour.

Base64 permet de faire passer des charges binaires par des systèmes qui n'acceptent que du texte, garde la configuration portable et s'accorde bien avec les API et le balisage qui intègrent de petites ressources. Encodez du texte en Base64 ou décodez-le, depuis du texte ou depuis des fichiers, avec conversion en direct pendant la frappe.

À quoi sert Base64

• Transport : Déplacez des octets en sécurité par e-mail, JSON, XML ou journaux sans corrompre les fins de ligne.
• Intégration : Intégrez de minuscules images ou polices en URI de données quand un fichier séparé est peu pratique.
• Interopérabilité : Partagez la même représentation compatible ASCII entre Windows, macOS, Linux et le web.
• Stockage : Rangez des blobs opaques dans des stockages orientés texte quand il n'y a pas de colonnes binaires.
• Débogage : Inspectez des réponses d'API ou des certificats comme des chaînes lisibles pendant le développement.
• Jetons : Lisez l'en-tête et la charge d'un JSON Web Token, qui sont du Base64 compatible URL sans remplissage.

Vos octets sont découpés en groupes de six bits ; chaque groupe correspond à un caractère de l'alphabet, et le remplissage garde une longueur multiple de quatre caractères.

Chaîne d'encodage

• Entrée : Le texte devient des octets dans l'encodage choisi ; les fichiers sont déjà des octets et sont lus directement.
• Regroupement des bits : Le flux d'octets est découpé pour que chaque index sélectionne l'un des soixante-quatre symboles.
• Remplissage : Les symboles = finaux indiquent quand le dernier bloc a eu besoin de bits de remplissage.
• Mise en forme : Le résultat reste sur une ligne, est coupé à 64 ou 76 caractères, ou est enveloppé en URI de données.
• Sortie : Vous obtenez du texte prêt à coller dans du code, un fichier de configuration, une feuille de style ou une requête d'API.
• Décodage : Les étapes se déroulent à l'envers pour retrouver la suite d'octets d'origine, ensuite lue comme du texte ou rendue comme un fichier.

Une URI de données transporte un fichier entier dans une seule chaîne, de sorte qu'une petite image, une icône ou une police peut vivre dans le HTML ou la feuille de style qui l'utilise plutôt que dans une requête séparée. C'est la raison la plus fréquente pour laquelle quelqu'un ouvre un encodeur Base64.

La forme d'une URI de données

La grammaire est data:, puis un type de média facultatif, puis des paramètres facultatifs, puis une virgule, puis la charge. Quand la charge est en Base64, le mot base64 apparaît juste avant la virgule. Le type de média compte plus qu'il n'y paraît : une URI de données sans type est prise pour du texte brut, si bien qu'un PNG écrit sans type s'affiche comme une image cassée dans une balise img et comme rien du tout en CSS. Cet outil écrit toujours le type de média, en le déduisant des octets de signature du fichier quand le fichier lui-même ne l'a pas déclaré.

Quand intégrer et quand s'abstenir

Intégrer supprime une requête, ce qui vaut le coup pour quelque chose de minuscule et immédiatement nécessaire : un logo dans un modèle d'e-mail, une icône dans une feuille de style, un substitut dans un jeu de test. Cela cesse vite d'en valoir la peine. Base64 ajoute environ un tiers de la taille, une ressource intégrée ne peut pas être mise en cache séparément du document qui la porte, et une grosse URI de données rend le document lui-même plus lent à analyser. En règle générale, intégrez ce qui se mesure en kilooctets et hébergez ce qui se mesure en centaines de kilooctets.

Dès qu'une chaîne Base64 doit voyager dans une URL, l'alphabet standard devient un problème, et la solution est une variante présente dans la norme depuis 2006.

Pourquoi le plus et la barre oblique cassent dans une URL

Une barre oblique sépare les segments de chemin, donc une charge qui en contient une est lue comme deux segments. Un plus est décodé comme un espace dans une chaîne de requête par convention ancienne, donc une charge qui en contient un revient modifiée. Un signe égal sépare un paramètre de sa valeur. Les trois apparaissent dans une sortie Base64 ordinaire, et c'est pourquoi la RFC 4648 section 5 définit la variante compatible URL : tiret pour le plus, tiret bas pour la barre oblique, et un remplissage que vous êtes libre d'omettre.

Lire un JSON Web Token

Un JWT est constitué de trois segments Base64 compatibles URL séparés par des points, sans remplissage. Collez un segment ici et il se décode sans changer de réglage, car l'alphabet est détecté à partir de la chaîne et le remplissage manquant est rétabli. L'en-tête et la charge sont du JSON lisible. La signature n'est pas destinée à être lue et reviendra sous forme d'octets — décodez-la vers un fichier plutôt que vers du texte, sinon cela ressemblera à un échec de décodage alors qu'il n'en est rien. Base64 n'est pas du chiffrement et la charge d'un JWT n'est pas secrète : quiconque détient le jeton peut la lire exactement comme vous venez de le faire.

La plupart des problèmes signalés avec Base64 ne sont pas des problèmes de Base64. C'est une chaîne qui a subi quelque chose en chemin, et ce qu'un outil peut faire d'utile, c'est dire quoi.

Les défauts à connaître

Une longueur qui laisse un caractère en trop ne peut pas être du Base64 du tout — aucune suite d'octets ne s'encode ainsi — donc c'est presque toujours un caractère perdu à la copie. Un remplissage au milieu signifie en général que deux charges ont été collées bout à bout. Les caractères hors alphabet sont d'ordinaire de la ponctuation introduite par un client de messagerie ou un traitement de texte, et l'espace insécable est le plus cruel parce qu'il est invisible. Un mélange de plus-barre et de tiret-tiret bas signifie qu'un rechercher-remplacer est passé sur la moitié de la chaîne. Un dernier caractère dont les bits restants ne sont pas nuls signifie que la chaîne a été modifiée après encodage, et c'est le seul de ces défauts sans symptôme visible, puisque ces bits sont écartés au décodage de toute façon.

Des habitudes qui évitent tout cela

Copiez depuis une vue en texte brut plutôt que depuis un rendu. Décidez une fois pour toutes si votre API attend du Base64 standard ou compatible URL et écrivez-le là où ceux qui l'appellent le verront. Quand une charge doit survivre à un corps de message ou à un fichier de certificat, coupez-la comme ce format l'exige plutôt que d'espérer que rien ne cassera la ligne à votre place. Et quand quelque chose ne va pas, regardez d'abord la longueur : c'est un test d'une seconde qui écarte la moitié des possibilités.

Connaître le surcoût de taille et la différence avec le chiffrement évite les attentes erronées dans les systèmes en production.

Référence rapide

• Attendez-vous à une augmentation de taille d'environ trente-trois pour cent par rapport au binaire brut de la même charge.
• L'alphabet MIME utilise A–Z, a–z, 0–9, plus + et / ; les variantes compatibles URL échangent les symboles mais suivent la même idée.
• Les caractères de remplissage gardent les décodeurs alignés quand le nombre d'octets n'est pas divisible par trois.
• Base64 est réversible et déterministe pour les alphabets standard, et c'est pourquoi il ne doit jamais remplacer le chiffrement.
• Les très gros fichiers deviennent de très longues chaînes ; les navigateurs peuvent sembler plus lents simplement parce que la chaîne est énorme.
• Quatre caractères Base64 portent toujours exactement trois octets, vous pouvez donc calculer la taille décodée avant de décoder quoi que ce soit.

Bonnes pratiques

Utilisez le bon outil : Base64 pour le transport et l'intégration, le chiffrement pour la confidentialité, la compression avant l'encodage quand la bande passante compte.

• Validez la sortie décodée dans un environnement de préproduction avant de faire confiance à des chaînes automatisées.
• Retirez les espaces des chaînes collées si vous avez copié depuis des documents mis en forme.
• Préférez un hébergement de ressources dédié pour les gros médias plutôt que d'énormes URI de données.
• Documentez si votre API attend du Base64 standard ou compatible URL, pour éviter des bogues subtils.
• Ne stockez jamais mots de passe ou secrets derrière un simple Base64 : ils se décodent instantanément.
• Compressez avant d'encoder, jamais après : la sortie Base64 est du texte et se compresse bien moins bien que les octets dont elle vient.

Cas d'usage courants

• Développement web : Expérimentez avec des URI de données ou simulez des réponses d'API portant des échantillons binaires.
• Automatisation : Préparez des charges pour des scripts qui n'acceptent qu'une entrée textuelle.
• E-mail et MIME : Comprenez les pièces jointes historiquement encodées pour des chemins SMTP sept bits.
• Configuration : Sérialisez de courtes clés ou sommes de contrôle dans des fichiers de type .env.
• Pédagogie : Montrez comment les couches de représentation s'empilent sur les bits bruts.
• Certificats : Lisez un bloc PEM sans ligne de commande — collez-le avec ses lignes BEGIN et END.

Les deux sens acceptent des fichiers, ce qui est inhabituel : la plupart des outils Base64 encodent un fichier puis vous obligent à coller du texte pour faire l'inverse.

Quels fichiers accepte chaque sens

L'encodage accepte tout, car Base64 est défini sur des octets arbitraires et il n'existe pas de fichier qu'il ne puisse représenter. Le décodage accepte les fichiers dont le contenu est du texte Base64 — .txt, .b64, .pem, .crt, .key et les autres extensions de texte brut — et refuse le reste au moment où vous le choisissez, avec un lien pour changer de sens, plutôt que de l'accepter et d'échouer plus tard. Une fois décodés, les octets sont identifiés par leurs propres nombres magiques, si bien qu'un PNG décodé est rendu en .png et un PDF décodé en .pdf.

Ce que comprend l'offre gratuite et ce qu'ajoute Pro

L'offre gratuite convertit un fichier à la fois, jusqu'à 25 Mo. C'est une décision commerciale et non une limite de l'appareil : ici un fichier de 25 Mo s'encode en quelques centièmes de seconde, et le travail ne touche jamais la page que vous regardez. Pro met jusqu'à cent fichiers en file d'attente, les convertit l'un après l'autre et vous les rend en un seul ZIP avec les noms en double rendus uniques — ce qui compte plus qu'il n'y paraît, car deux fichiers nommés photo.png venant de dossiers différents deviendraient sinon une seule entrée et l'archive contiendrait discrètement moins de fichiers que vous n'en avez convertis.

Base64 est une représentation, pas une compression et pas une protection. Il agrandit les données, il est trivialement réversible par n'importe qui, et il ne devrait jamais être la seule chose entre un secret et la personne qui lit votre fichier de configuration. Il ne peut pas non plus réparer des données déjà fausses avant l'encodage.

Tout s'exécute sur votre appareil. La conversion a lieu en dehors de la page, la saisie reste donc fluide quelle que soit la taille de la charge, et un fichier de 25 Mo est converti en environ quinze millisecondes sur un navigateur de bureau actuel. Rien n'est envoyé, et l'outil continue de fonctionner réseau coupé une fois la page chargée.

• Encodeur Base64
• Décodeur Base64
• Encodeur/décodeur d'URL
• Tous les convertisseurs
• Générateur de hachage
• Générateur d'UUID
• Formateur JSON
• Générateur de QR code
• Lecteur de QR code
• Convertisseur de couleurs
• Compresser une image d'abord
• Générateur de favicon
• Échappement JSON
• Minificateur JSON
• Nettoyeur de texte
• Tous les outils de texte