Skip to content

Encodeur / Décodeur Base64

Collez du texte, obtenez du Base64. Ou dans l'autre sens.

Le Base64 augmente la taille des données d'environ 33 % (4 caractères pour chaque 3 octets).

Comment fonctionne l'encodage Base64

Le Base64 convertit des données binaires en un format texte sûr en utilisant 64 caractères ASCII imprimables (A–Z, a–z, 0–9, +, /). Chaque groupe de 3 octets d'entrée devient exactement 4 caractères Base64 — d'où l'augmentation de taille d'environ 33 %. Le rembourrage avec des signes = garantit que la longueur de sortie est toujours un multiple de 4.

Cet outil encode d'abord le texte en octets UTF-8 (via l'API TextEncoder du navigateur), puis encode ces octets en Base64. Cela signifie qu'il gère correctement les caractères accentués, les emojis, les caractères chinois et tout autre texte Unicode, pas seulement l'ASCII. La variante URL-safe remplace + par -, / par _ et supprime le rembourrage =, rendant la sortie sûre pour être incluse dans les URLs sans encodage supplémentaire.

Sources

L'encodage Base64 est formellement défini dans la RFC 4648 — Les encodages de données Base16, Base32 et Base64 (S. Josefsson, octobre 2006, rfc-editor.org/rfc/rfc4648). La section 4 définit le Base64 standard, et la section 5 définit l'alphabet URL-safe (- et _ remplaçant + et /). Cet outil implémente les deux alphabets.

Ce qui est là — et ce qui ne l'est pas

Conversion bidirectionnelle, basculement URL-safe, correction UTF-8 (pas seulement ASCII), boutons de copie pour les deux volets et un bouton d'inversion qui bascule le sens et déplace la sortie dans l'entrée. L'encadré d'information vous rappelle la surcharge de taille de 33 % — utile pour décider si le Base64 est approprié pour votre cas d'utilisation.

Ce qui n'est pas là : l'encodage de fichiers binaires (glisser-déposer un .jpg pour obtenir du Base64) n'est pas dans la v1 — cela nécessite FileReader API et le rendu d'aperçu. Également absent : Base32, encodage Base16/hex ou streaming pour les grandes entrées. Ces fonctionnalités ont assez de portée pour appartenir à des outils séparés.

Qu'est-ce que le Base64 et quand l'utiliser

Le Base64 encode les données binaires en texte ASCII en utilisant 64 caractères imprimables (A–Z, a–z, 0–9, +, /). La sortie est toujours environ 33 % plus grande que l'entrée — un compromis nécessaire pour rendre les données binaires arbitraires sûres pour les canaux texte uniquement.

Pièces jointes email (MIME) : le cas d'utilisation originel. Les fichiers binaires (images, PDF) ne pouvaient pas être transmis de manière fiable via les protocoles email texte — le Base64 les encode en ASCII sûr pour survivre à n'importe quel relais de messagerie.

Data URIs : intégrer des images directement en HTML ou CSS (<img src="data:image/png;base64,..."/>) élimine les requêtes HTTP supplémentaires. Idéal pour les petites icônes et les images inline où le coût d'aller-retour dépasse la surcharge de taille.

JWTs (JSON Web Tokens) : l'en-tête et le contenu sont encodés en Base64URL — la variante URL-safe qui remplace + par - et / par _. Les JWTs ne sont pas chiffrés ; ils sont seulement encodés. N'importe qui peut les décoder instantanément.

Basic Auth API : l'authentification HTTP Basic encode nom:motdepasse en Base64 et l'envoie dans l'en-tête Authorization (Authorization: Basic dXNlcjpwYXNz). C'est une commodité de transport, pas du chiffrement — utilisez toujours HTTPS.

Données binaires en JSON : JSON ne peut pas représenter des octets bruts. Le Base64 comble cette lacune pour les miniatures d'images, les petits fichiers ou les données de protocole binaire qui doivent voyager dans un payload JSON.

Outils connexes : Encodeur / décodeur URL, Générateur de hachage, Décodeur JWT, et Convertisseur de base numérique.

Le Base64 n'est PAS du chiffrement

L'encodage Base64 est entièrement réversible sans clé secrète — n'importe qui peut le décoder en quelques millisecondes. C'est de l'obscurcissement au mieux, pas de la sécurité. N'utilisez jamais le Base64 pour « cacher » des données sensibles dans une page web, une réponse API ou du code côté client. Il ne fournit aucune protection.

Base64 vs Base64URL : le Base64 standard utilise + et /, qui sont des caractères spéciaux dans les URLs et peuvent casser les chaînes de requête. Base64URL les remplace par - et _, et omet le rembourrage =. Utilisez toujours Base64URL pour les URLs, les JWTs et les valeurs de cookies.

Erreur courante : traiter un JWT encodé en Base64 comme « chiffré ». Le contenu est entièrement lisible par tout le monde — y compris le navigateur de l'utilisateur. Seule la signature (HMAC ou RSA) garantit l'intégrité ; le contenu n'est pas confidentiel. Décodez n'importe quel en-tête et contenu JWT dans l'outil ci-dessus et voyez par vous-même.

Pour un vrai chiffrement, utilisez AES-256 ou RSA, pas le Base64. Le Base64 est un encodage de transport, pas une primitive de sécurité.

Questions fréquentes

À quoi sert le Base64 ?
Le Base64 sert à transmettre des données binaires de manière sécurisée via des canaux texte uniquement. Utilisations courantes : intégrer des images en CSS ou HTML (data URLs), tokens JWT, en-têtes Basic Auth (nom d'utilisateur:mot de passe → base64), pièces jointes MIME et stockage de blobs binaires en JSON ou XML.
Pourquoi le Base64 augmente-t-il la taille des données d'environ 33 % ?
Le Base64 encode chaque groupe de 3 octets en 4 caractères (chaque caractère représente 6 bits, 4 × 6 = 24 bits = 3 octets). Donc 3 octets → 4 caractères = 4/3 ≈ 1,33× d'augmentation de taille. Cette surcharge est le coût pour rendre les données binaires imprimables.
Quelle est la différence entre le Base64 standard et URL-safe ?
Le Base64 standard (RFC 4648 section 4) utilise + et / comme 62e et 63e caractères, plus = pour le rembourrage. Ces caractères ont une signification particulière dans les URLs. Le Base64 URL-safe (RFC 4648 section 5) remplace + par - et / par _ et omet généralement le rembourrage =. Utilisez URL-safe pour les tokens JWT, paramètres d'URL et noms de fichiers.
Où le Base64 est-il défini ?
RFC 4648 — « Les encodages de données Base16, Base32 et Base64 » par S. Josefsson (octobre 2006). La section 4 définit le Base64 standard et la section 5 définit l'alphabet URL-safe. Disponible sur rfc-editor.org/rfc/rfc4648.
Cela gère-t-il les emojis et les caractères non-ASCII ?
Oui. L'outil utilise l'API TextEncoder du navigateur pour convertir votre entrée en octets UTF-8 avant l'encodage. Au décodage, il utilise TextDecoder pour reconstruire la chaîne originale. Cela gère correctement les emojis (🎉), les lettres accentuées (é, ü, ñ), les caractères chinois et tout texte Unicode.
Pourquoi la sortie Base64 est-elle toujours plus grande que l'entrée ?
Le Base64 encode chaque groupe de 3 octets de données binaires en 4 caractères ASCII — un ratio 4:3. Cela rend la sortie exactement 33,3 % plus grande. Des caractères de rembourrage (=) sont ajoutés pour garantir que la longueur de sortie est un multiple de 4. Pour les petites entrées, la surcharge est proportionnellement plus élevée ; pour les grands fichiers, elle est constamment d'environ 33 %. Cette surcharge est inévitable : c'est le coût d'encoder des octets 8 bits en utilisant uniquement des caractères 6 bits.
Puis-je utiliser le Base64 pour envoyer des fichiers via API ?
Oui, et c'est courant pour les petits fichiers (images, PDF inférieurs à quelques centaines de Ko). Encodez le fichier en Base64 et incluez-le comme champ texte dans votre payload JSON. Pour les grands fichiers, préférez multipart/form-data ou des URLs pré-signées (S3, Azure Blob) — l'encodage Base64 ajoute 33 % de surcharge de taille et augmente l'utilisation de la mémoire côté client et serveur pendant le traitement.

Par Bam's Thinkery — Mis à jour le