Encodeur de texte en Base64
Encodez n'importe quelle chaîne en Base64 dans votre navigateur, avec une gestion correcte des octets UTF-8 et un alphabet standard ou compatible URL, prêt à copier ou télécharger.
Ce que fait l'outil
- UTF-8 par défaut pour que les accents et les emoji fassent l'aller-retour proprement
- Alphabet standard ou compatible URL pour les JWT et les paramètres de requête
- Copie dans le presse-papiers ou téléchargement de la sortie encodée
- Fonctionne localement en WebAssembly, rien n'est envoyé
L'encodage de texte en Base64 transforme n'importe quelle chaîne en l'alphabet ASCII de 64 caractères pour qu'elle survive aux en-têtes HTTP, aux valeurs JSON, aux fichiers de configuration et aux data URI, et tout se passe dans votre navigateur sans aucun envoi. La plupart des gens arrivent ici pour construire un en-tête HTTP Basic Auth, glisser une valeur dans une configuration ou un blob JSON, ou préparer un segment de JWT, collant souvent des clés d'API et des identifiants en production qu'ils préféreraient ne pas envoyer à un serveur tiers financé par la publicité.
Ce que cette conversion fait réellement (et ce qu'elle ne fait PAS)
Base64 est un encodage, pas un chiffrement. Il n'ajoute aucune confidentialité et est trivialement réversible par quiconque, il ne doit donc jamais servir à "cacher" un secret. Son seul rôle est de rendre des octets arbitraires transportables à travers des canaux uniquement textuels.
La sortie est toujours environ 33 % plus grande que l'entrée. Chaque tranche de 3 octets d'entrée devient exactement 4 caractères ASCII, donc une chaîne de 9 octets devient 12 caractères, une chaîne de 30 octets devient 40, et ainsi de suite. Il n'y a aucune perte de qualité ni compression : ce gonflement est structurel. Si ce Base64 est ensuite servi par HTTP avec gzip ou Brotli, les motifs répétitifs se compressent bien et le surcoût effectif tombe souvent à environ 5 à 10 %, mais la chaîne brute elle-même reste un tiers plus grande.
Le texte doit être converti en octets avant l'encodage, et l'encodage des octets compte. La chaîne « café » ou un emoji s'encode en octets totalement différents selon UTF-8 ou Latin-1, et choisir le mauvais est la cause la plus fréquente d'allers-retours corrompus. Cet encodeur utilise UTF-8 par défaut pour que les caractères multi-octets survivent au trajet retour.
Les signes = finaux ne sont qu'un alignement de longueur, pas des données. Un octet restant produit ==, deux octets restants produisent un seul =, et un multiple exact de trois octets ne produit aucun remplissage. Le remplissage peut être omis dans les contextes où la longueur est déjà connue, mais la plupart des décodeurs l'attendent. Il existe aussi deux alphabets : le Base64 standard utilise + et /, tandis que le Base64 compatible URL (RFC 4648 §5, la variante employée par les JWT) les remplace par - et _ pour que la chaîne soit sûre dans les URL, les paramètres de requête et les noms de fichiers.
Une chose que cet outil ne fait PAS par défaut, c'est insérer des sauts de ligne MIME. Le Base64 de style e-mail insère un saut de ligne tous les 76 caractères, et cet espace blanc est invalide pour de nombreux décodeurs, ce qui casse l'analyse en aval si vous le collez dans un en-tête ou une valeur JSON. Gardez le retour à la ligne désactivé, sauf si vous alimentez spécifiquement un consommateur e-mail ou PEM qui l'exige.
Quand choisir Texte vers Base64
Optez pour Base64 lorsque vous avez une petite charge utile textuelle qui doit transiter par un canal uniquement textuel : un en-tête HTTP Basic Auth (le Base64 de user:pass), un minuscule blob de configuration, une valeur JSON ou localStorage, ou un data URI pour un très petit fichier. Choisissez l'alphabet compatible URL quand le résultat va dans une URL, une chaîne de requête, un nom de fichier ou un JWT ; choisissez le standard sinon. Pour de gros fichiers binaires, la pénalité de taille de 33 % rend le transfert binaire brut préférable, donc n'encodez pas en Base64 un fichier de plusieurs mégaoctets juste pour le déplacer. Quand vous devez relire une chaîne Base64, utilisez le sens inverse avec l'outil de décodage Base64 vers texte.
Comment convertir du texte en Base64
- Ouvrez cette page, verrouillée sur l'encodage (texte vers Base64).
- Choisissez la variante d'alphabet : standard pour un usage général, ou compatible URL pour les JWT, les paramètres de requête et les noms de fichiers.
- Collez ou saisissez votre texte dans le champ de saisie.
- Cliquez sur convertir pour produire la sortie Base64.
- Copiez le résultat dans votre presse-papiers ou téléchargez-le sous forme de fichier.
Aucun envoi. Tout s'exécute sur votre appareil.
Cet encodeur est compilé de Rust vers WebAssembly et s'exécute entièrement dans l'onglet de votre navigateur. Votre texte est transformé en octets puis encodé en Base64 localement, sans aucune requête réseau, il continue donc de fonctionner hors ligne une fois la page chargée. Rien n'est envoyé, ce qui signifie qu'il n'y a rien sur un serveur à divulguer ou à supprimer. Vous pouvez le vérifier vous-même : ouvrez les DevTools de votre navigateur, surveillez l'onglet Réseau, et encodez une chaîne, aucune requête ne part. Cela compte ici parce que les valeurs que les gens encodent en Base64 sont souvent les chaînes les plus sensibles qu'ils manipulent : clés d'API, mots de passe dans des identifiants Basic Auth, et charges utiles de jetons qui ne devraient jamais être collées sur un site tiers.
Aucune limite
Aucune limite de taille de fichier ou de nombre de caractères, aucun filigrane, aucune inscription, aucune publicité et aucun suivi. Encodez autant de chaînes que vous le souhaitez.
Questions fréquentes
- L'encodage Base64 est-il la même chose que le chiffrement ?
- Non. Base64 est un encodage réversible qui n'ajoute aucune confidentialité, et n'importe qui peut le décoder en texte d'origine en quelques secondes. Utilisez-le pour rendre des octets transportables sur des canaux textuels, jamais pour protéger un secret.
- Pourquoi ma sortie Base64 est-elle environ un tiers plus longue que le texte d'origine ?
- Base64 fait correspondre chaque tranche de 3 octets d'entrée à exactement 4 caractères ASCII, un ratio fixe de 4 pour 3 qui ajoute environ 33 % de longueur. Cette croissance est structurelle plutôt qu'un réglage, même si servir le résultat avec gzip ou Brotli peut réduire le surcoût effectif à environ 5 à 10 %.
- Que signifient les signes = à la fin du Base64 ?
- Ce sont des caractères de remplissage qui alignent la sortie sur un multiple de quatre caractères, ils ne font pas partie de vos données. Un octet restant donne
==, deux octets restants donnent un seul=, et un multiple exact de trois octets n'en donne aucun. - Quelle est la différence entre le Base64 standard et le Base64 compatible URL ?
- Le Base64 standard utilise les caractères
+et/, qui peuvent casser à l'intérieur des URL et des noms de fichiers. Le Base64 compatible URL, défini dans la RFC 4648 §5 et utilisé par les JWT, les remplace par-et_pour que la chaîne soit sûre dans les URL, les paramètres de requête et les noms de fichiers. - Comment encoder correctement en Base64 du texte avec des accents ou des emoji ?
- Assurez-vous que le texte est converti en octets en UTF-8 avant l'encodage, ce que cet outil fait par défaut. « café » ou un emoji produit des octets différents selon UTF-8 ou Latin-1, et les encodages incompatibles sont la première cause d'allers-retours corrompus.
- Cet outil de texte vers Base64 envoie-t-il mon texte à un serveur ?
- Non. L'encodage s'exécute en WebAssembly dans votre navigateur sans aucune requête réseau, votre texte ne quitte donc jamais l'appareil. Vous pouvez le vérifier en surveillant l'onglet Réseau des DevTools pendant que vous encodez, aucune requête n'est faite.
- La sortie Base64 doit-elle comporter des sauts de ligne tous les 76 caractères ?
- Uniquement pour les contextes e-mail et PEM qui attendent un retour à la ligne MIME. Pour les en-têtes HTTP, les valeurs JSON et les data URI, vous devez laisser le retour à la ligne désactivé, car les sauts de ligne insérés sont invalides pour de nombreux décodeurs et casseront la valeur en aval.
- Comment créer une valeur Base64 pour un en-tête HTTP Basic Auth ?
- Concaténez le nom d'utilisateur et le mot de passe sous la forme
user:passet encodez cette seule chaîne en Base64. Le résultat devient l'identifiant dans un en-têteAuthorization: Basic <valeur>. - Puis-je encoder en toute sécurité une clé d'API ou un mot de passe ici en Base64 ?
- Oui, parce que l'encodage se passe localement et que la valeur ne touche jamais un serveur. N'oubliez pas que le Base64 obtenu n'est pas chiffré, donc quiconque le voit peut décoder la clé ou le mot de passe d'origine.
- Comment décoder du Base64 en texte ?
- Utilisez le sens inverse, qui lit une chaîne Base64 et renvoie le texte d'origine. L'outil de décodage Base64 vers texte traite localement les entrées standard et compatibles URL.
Pour le sens inverse et un décodage complet, utilisez l'outil de décodage Base64 vers texte. Parcourez le reste des outils texte et données.