Outil encodeur Base64 en ligne

1. 1

   Ajoutez ce que vous voulez encoder

   Saisissez ou collez dans la zone de texte, ou déposez un fichier sur la zone d'import. Tout type de fichier fonctionne, car l'encodeur lit des octets et n'a jamais besoin de comprendre le format.

2. 2

   Choisissez la variante de Base64

   Prenez un préréglage — Standard, MIME, PEM ou Compatible URL — ou réglez vous-même l'alphabet, le remplissage et la largeur de ligne. Activez Data URI si la chaîne va dans du HTML ou du CSS.

3. 3

   Encodez et copiez

   Appuyez sur Encoder. Le résultat apparaît avec sa taille et son surcoût mesurés ; copiez-le dans le presse-papiers ou téléchargez-le en fichier texte. Rien n'est jamais envoyé à un serveur.

Le Base64 réécrit des octets quelconques avec 64 caractères ASCII imprimables — A-Z, a-z, 0-9 et deux autres qui dépendent de la variante. Il existe parce qu'une grande quantité de systèmes ont été conçus pour transporter du texte et non des octets : champs de chaîne JSON, documents XML, corps d'e-mail, en-têtes HTTP, configuration YAML, lignes de journal, messages de chat. Donner à l'un d'eux un flux d'octets brut le corrompt, généralement en silence. Le Base64 vous donne quelque chose que ces systèmes transporteront sans modification, et qui redonne exactement les octets de départ.

Le coût est la taille. Trois octets deviennent quatre caractères, la charge grossit donc d'un tiers avant même de compter le remplissage et les retours à la ligne — une image de 1 Mo fait environ 1,37 Mo de Base64. C'est un bon échange pour une icône de 2 Ko que vous voulez intégrer, et un mauvais pour une photographie de 4 Mo que vous alliez servir depuis une URL de toute façon. L'outil mesure l'expansion réelle de votre entrée et l'affiche à côté du résultat au lieu de citer les 33 % des manuels, car le retour à la ligne et le préfixe d'un data URI la font tous deux monter.

Quatre réglages changent la chaîne obtenue. Ils sont indépendants à dessein : la plupart des encodeurs en lient deux et devinent à votre place, ce qui va très bien jusqu'au moment où le système que vous alimentez veut la combinaison que la supposition a écartée.

L'alphabet : standard ou compatible URL

Soixante-deux des 64 caractères sont identiques partout. Les deux derniers sont + et / en Base64 standard (RFC 4648 section 4) et - et _ en Base64 compatible URL, aussi appelé base64url (section 5). La différence compte partout où la chaîne rencontre un analyseur : + veut dire espace dans une chaîne de requête, / sépare les segments de chemin, et les deux sont gênants dans un nom de fichier. Si la valeur part dans une URL, un JWT ou un nom de fichier, prenez le compatible URL ; sinon, le standard est ce que tout attend.

Le remplissage

Le Base64 travaille par groupes de trois octets. Quand l'entrée ne se divise pas exactement, un ou deux caractères = sont ajoutés pour que la longueur de sortie soit toujours un multiple de quatre, ce qui indique au décodeur où les données s'arrêtent précisément. Le Base64 standard l'exige. Le base64url le permet, et les JWT l'interdisent expressément — d'où le fait que le remplissage soit ici un interrupteur à part et non quelque chose qui suit l'alphabet. Le désactiver ne change jamais les octets décodés ; un décodeur strict peut simplement refuser la chaîne.

Le retour à la ligne

Une seule ligne continue convient à un champ JSON et pas à un e-mail. La RFC 2045 limite une ligne de corps MIME à 76 caractères et impose CRLF, donc une pièce jointe Base64 sans coupure n'est pas un corps MIME valide. PEM — le format qui enveloppe clés privées, certificats et matériel SSH entre des lignes BEGIN et END — utilise 64. La largeur va ici de 4 (un quantum Base64, la ligne la plus étroite qui ne coupe pas un groupe) jusqu'à 998, la plus longue ligne que la RFC 5322 autorise dans un message, et le terminateur est un contrôle séparé parce que les deux normes ne s'accordent pas dessus.

Encoder chaque ligne séparément

Par défaut toute l'entrée forme une seule chaîne. Activez ceci et chaque ligne est encodée indépendamment, ce qui vous donne une colonne de valeurs Base64 à partir d'une colonne d'entrées — la forme voulue quand vous avez collé une liste de clés d'API, d'identifiants ou de messages courts et qu'il faut encoder chacun à part. Chaque ligne garde ses propres octets de terminaison, donc les résultats se recomposent toujours exactement en le document de départ.

Toutes les variantes ci-dessous encodent les mêmes octets et se décodent vers les mêmes octets. Ce qui diffère, ce sont les caractères qui apparaissent et l'endroit où tombent les coupures — et un système qui en attend une rejettera généralement une autre plutôt que de s'en accommoder discrètement. Cet outil propose en préréglages les quatre dont on a réellement besoin :

Deux autres variantes existent et ne sont délibérément pas proposées ici. L'ASCII Armor d'OpenPGP ajoute une somme de contrôle CRC-24 et un bloc d'en-tête, et l'UTF-7 d'IMAP utilise un alphabet modifié avec d'autres règles d'échappement — ce sont deux formats distincts portant l'étiquette Base64, et les offrir sous forme de case à cocher produirait une sortie qui n'est ni l'un ni l'autre.

Un data URI est une chaîne Base64 précédée d'un type de média, et il permet à un fichier de vivre dans le document qui l'utilise au lieu d'être au bout d'une URL. Activez l'option data URI et le préfixe est construit pour vous, avec le type de média lu dans les premiers octets du fichier plutôt que dans son extension — ainsi un PNG que quelqu'un a renommé en .jpg est quand même étiqueté image/png, et un fichier qui arrive de Windows sans aucun type de média est quand même identifié correctement. Cela en vaut la peine quand :

• La ressource est petite et toujours nécessaire — une icône, une puce, un logo, un fond d'un pixel. L'intégrer supprime une requête qui aurait bloqué le rendu.
• Vous prototypez — un fichier HTML unique qui porte ses propres images est bien plus facile à envoyer par e-mail, coller dans un ticket ou déposer dans un bac à sable.
• Il n'y a nulle part où l'héberger — un README Markdown, une signature d'e-mail, ou un fichier de configuration qui prend une chaîne et pas un chemin.
• La police est un sous-ensemble — une petite police d'icônes intégrée en CSS évite le flash de texte invisible qu'une requête séparée peut provoquer.

Quand un data URI est la mauvaise réponse

Une ressource intégrée ne peut pas être mise en cache séparément, donc chaque page qui l'intègre la paie de nouveau, et elle ne peut pas être servie dans un format moderne aux navigateurs qui le prennent en charge. Elle gonfle aussi d'un tiers le fichier où elle vit, et ce fichier est en général le HTML ou le CSS du chemin critique. En règle générale, intégrez en dessous de quelques kilo-octets et faites un lien au-dessus — et n'intégrez jamais quelque chose qui apparaît sur plus d'une poignée de pages.

Le Base64 encode des octets, et un texte n'a pas d'octets tant que quelqu'un n'a pas choisi un encodage — « encode ce texte » est donc une demande incomplète. Le mot cafe avec accent aigu donne Y2Fmw6k= en UTF-8 et Y2Fm6Q== en Latin-1. Les deux sont corrects ; un seul sera compris par ce à quoi vous l'envoyez. La plupart des encodeurs en ligne proposent UTF-8 et rien d'autre, ce qui est juste presque toujours et silencieusement faux le reste du temps. Cinq sont proposés ici :

Fins de ligne

Une zone de texte sur une page web ne peut pas contenir de retour chariot : la spécification HTML impose que sa valeur soit normalisée en sauts de ligne, donc y coller un fichier Windows et l'encoder vous donne la chaîne que ce fichier aurait sous Linux, pas celle qu'il a réellement. C'est une réponse authentiquement fausse sans rien à l'écran qui le laisse deviner, et le contrôle de fin de ligne est donc ici une affaire de correction plutôt que de confort — réglez-le sur CRLF et l'encodeur remet les retours chariot en place avant d'encoder.

N'importe quel fichier convient. L'encodeur n'a jamais besoin de comprendre un format — il lit des octets et fait de l'arithmétique dessus — donc images, polices, PDF, archives, vidéos, fichiers sans extension et fichiers dont le système d'exploitation n'a pas su identifier le type s'encodent tous correctement. Le fichier est lu sur votre appareil et les octets n'en sortent jamais. Comme le résultat occupe en mémoire environ 2,7 fois la taille du fichier une fois conservé sous forme de texte, les très grands résultats sont montrés en aperçu tandis que Copier et Télécharger donnent toujours la chaîne complète.

Ce que comprend la version gratuite

Des fichiers jusqu'à 25 Mo, un à la fois, et toutes les options d'encodage : les deux alphabets, le remplissage dans les deux sens, les quatre préréglages, n'importe quelle largeur de ligne, les data URI, le mode par lignes et les cinq encodages de texte. Rien qui touche à la correction de la sortie n'est derrière le péage, car une version gratuite qui vous rend une chaîne que votre décodeur rejette n'est pas une version gratuite.

Ce qu'ajoute Pro

L'échelle, et seulement l'échelle. Jusqu'à 20 fichiers en une passe avec un unique ZIP qui rassemble les résultats, et aucune limite de taille imposée — Pro va jusqu'à ce que votre appareil peut réellement gérer, pas jusqu'à une constante plus grande que nous aurions choisie. Aucun concurrent examiné n'accepte plus d'un fichier à la fois, le lot est donc la partie qui n'existe nulle part ailleurs.

Utilisez cette page quand vous avez déjà du texte ou un fichier et qu'il vous faut sa représentation Base64. Utilisez le décodeur quand vous partez d'une chaîne Base64 et voulez récupérer le contenu d'origine.

• Intégrer une ressource — un data URI pour une icône, une puce ou une petite police, collé directement dans du HTML ou du CSS.
• Remplir un champ d'API — un corps de requête ou un fichier de configuration qui prend un blob Base64 plutôt qu'un envoi de fichier.
• Préparer un corps MIME — des lignes de 76 caractères avec CRLF, pour qu'une pièce jointe soit une partie de message valide.
• Construire un jeton compatible URL — du base64url sans remplissage, pour un segment de JWT, un paramètre de requête ou un nom de fichier.
• Faire passer du binaire par du texte — coller quelque chose dans un chat, un ticket, un journal ou un terminal qui ne transporte que du texte.
• Produire des fixtures de test — une chaîne Base64 connue pour un test unitaire, dans la variante exacte attendue par le code testé.

On se tourne souvent vers le Base64 par réflexe, et il y a quatre tâches pour lesquelles il a l'air adapté et ne l'est pas.

• Cacher un secret — le Base64 n'est pas du chiffrement. N'importe qui le décode en une étape, et un mot de passe en Base64 dans un fichier de configuration est un mot de passe en clair avec de la syntaxe en plus. Utilisez de la vraie cryptographie.
• Vérifier l'intégrité — le Base64 ne dit rien sur un éventuel changement des données. Utilisez un hachage — notre générateur produit SHA-256 et consorts sur le même appareil.
• Réduire quoi que ce soit — il agrandit toujours les données d'un tiers. Si le but est une charge plus petite, compressez d'abord et encodez les octets compressés.
• Servir de gros médias — une vidéo ou une photographie intégrée ne peut être ni mise en cache, ni demandée par plages, ni diffusée, et elle bloque le document où elle vit. Servez-la depuis une URL.

Les demandes pour lesquelles cette page sert le plus souvent, dans l'ordre où elles arrivent :

• Construire un data URI pour une petite image ou police lors du prototypage HTML ou CSS.
• Préparer une charge utile pour une API ou un fichier de configuration qui stocke un blob Base64.
• Couper le corps d'un certificat ou d'une clé à 64 caractères pour correspondre au PEM qui l'entoure.
• Produire un corps MIME de 76 caractères pour une pièce jointe construite à la main.
• Encoder une valeur pour un segment de JWT ou un paramètre d'URL sans remplissage.
• Faire passer du binaire par un système qui n'autorise que du texte brut en transit.
• Transformer un fichier local en chaîne collable quand aucun envoi binaire n'est possible.
• Générer des fixtures pour de l'outillage ou des tests qui attendent une variante Base64 précise.

Le Base64 standard est compris par tous les langages et plateformes largement utilisés. Ce sont les variantes qui rendent la compatibilité tranchante : un décodeur écrit pour le Base64 standard rejettera - et _, un décodeur strict rejettera un = manquant, et un analyseur MIME rejettera un corps sans coupure. Choisissez le préréglage qui nomme le système que vous alimentez plutôt que celui qui paraît le plus propre et, en cas de doute, le standard avec remplissage est ce que le plus grand nombre de décodeurs acceptent.

L'encodage est sans perte dans les deux sens : décoder avec un outil compatible restitue exactement les octets de départ. Le seul endroit où des données peuvent se perdre est avant même que le Base64 intervienne — si vous choisissez un encodage de caractères incapable de représenter un caractère de votre texte, cet outil nomme le caractère et sa position et refuse, au lieu de le remplacer par un point d'interrogation et de vous rendre une chaîne fausse avec assurance, ce que ferait une substitution silencieuse.

L'encodage s'exécute sur votre appareil avec la méthode la plus rapide offerte par votre navigateur, et se rabat sur une méthode plus lente produisant exactement la même chaîne lorsque la première est absente. Mesuré sur un navigateur de bureau, un fichier de 16 Mo s'encode en moins de 5 millisecondes par la voie rapide et en moins de 40 par la voie de secours ; l'encodage de fichiers se fait hors du fil principal de la page, l'interface reste donc réactive pendant l'opération.

• Encodeur/décodeur Base64
• Décodeur Base64
• Encodeur/décodeur d'URL
• Générateur de hachage
• Formateur JSON
• Générateur de QR code
• Générateur d'UUID
• Compresser une image
• HEIC vers JPG
• Nettoyeur de texte
• Échappement JSON
• Tous les convertisseurs