Codeur/Décodeur Base64
Encoder et décoder rapidement Base64 avec support de texte UTF-8
Sélectionner la Méthode de Conversion
Qu'est-ce que Base64 ?
Base64 est une méthode utilisant 64 caractères imprimables pour représenter des données binaires. Ces 64 caractères comprennent les majuscules A-Z, minuscules a-z, chiffres 0-9, et les deux symboles + et /. Comme seuls des caractères imprimables sont utilisés, les données encodées en Base64 peuvent être transmises en toute sécurité dans des environnements ne supportant que le texte, comme les emails, pages web et JSON. Les données encodées augmentent d'environ 33% par rapport aux données originales. Base64 est apparu pour la première fois en 1987 dans le protocole PEM pour transmettre des données binaires en toute sécurité dans les emails. Aujourd'hui, c'est l'un des standards Internet, largement utilisé dans divers scénarios, des pièces jointes aux tokens JWT, des images embarquées à la transmission de données. Presque tous les langages de programmation intègrent des fonctions d'encodage et décodage Base64.
Utilisation
Mode d'emploi
- Collez votre texte dans la zone de saisie de gauche.
- Choisissez l'opération « Encoder » ou « Décoder ».
- Les résultats s'affichent automatiquement à droite.
- Cliquez sur le bouton Copier pour enregistrer le résultat.
Pièges courants
- Base64 est un encodage, pas un chiffrement : quiconque possède le texte peut le décoder, ne l'utilisez pas pour protéger des secrets.
- En cas d'échec du décodage, vérifiez le remplissage, les sauts de ligne, les caractères Base64 URL-safe ou les guillemets parasites.
Cas d’utilisation
Principe technique
Base64 est l'un des plusieurs codages binaire-vers-texte spécifiés dans le RFC 4648 (S. Josefsson, octobre 2006), aux côtés de Base16 (hexadécimal) et Base32. Le nom « Base64 » et l'alphabet ont été définis à l'origine pour Privacy-Enhanced Mail (RFC 989, 1987), où PEM enveloppait des éléments binaires S/MIME et X.509 dans une enveloppe ASCII imprimable pour qu'ils survivent aux transports 7 bits. Le même alphabet est ensuite devenu le standard de facto pour MIME (RFC 2045), les signatures JWT (RFC 7519), les URI data: en HTML (RFC 2397), les blobs de clés publiques SSH (RFC 4253 §6.6) et les fichiers pointeurs Git LFS (qui stockent les hachages SHA-256 en Base64). Les packfiles de Git eux-mêmes ne sont PAS en Base64 — ils utilisent un encodage delta avec compression zlib, et les identifiants d'objets Git sont des chaînes hexadécimales SHA-1 de 40 caractères, pas du Base64. Le coût : chaque groupe de 3 octets d'entrée devient 4 caractères de sortie, donc la sortie encodée fait exactement 4/3 de la taille (33,3% de surcharge). Pour un blob binaire de 10 Mo, la forme encodée fait environ 13,3 Mo. Le mécanisme : on découpe l'entrée en groupes de 3 octets (24 bits) ; chaque groupe est divisé en quatre valeurs de 6 bits ; chaque valeur de 6 bits sélectionne un caractère dans un alphabet de 64 caractères. L'alphabet canonique est A-Z (indices 0-25), a-z (26-51), 0-9 (52-61), '+' (62), '/' (63), avec '=' comme caractère de remplissage. L'exemple classique du RFC 4648 : « Man » (0x4d 0x61 0x6e) se compacte en la valeur 24 bits 0x4d616e ; découpé en blocs de 6 bits donne 0x0d 0x16 0x0e 0x0a, mappé à « TWFu ». Quand la longueur d'entrée n'est pas un multiple de 3, le dernier groupe est complété par des zéros à droite : 1 octet restant → 2 blocs significatifs de 6 bits + « == » (2 caractères de remplissage) ; 2 octets restants → 3 blocs significatifs + « = » (1 caractère de remplissage). Les caractères de remplissage ne portent aucune information, mais ils rendent la longueur de codage une fonction déterministe de la longueur d'entrée et permettent aux décodeurs de rejeter les entrées tronquées. Dans le navigateur, Base64 a deux pièges bien connus. Premièrement, `btoa` et `atob` (les variantes DOMString) opèrent sur des unités de code Latin-1, pas des octets — passer une chaîne contenant U+00E9 (é) ou U+4E2D (中) lance une InvalidCharacterError. La page contourne ce problème en passant par `TextEncoder().encode(str) (toujours UTF-8) avant d'appeler btoa, et `TextDecoder().decode(bytes)` après atob. Les caractères multi-octets UTF-8 s'étendent : « 你 » fait 3 octets (0xe4 0xbd 0xa0) → 4 caractères Base64 (8 caractères Base64 pour « 你好 »). Deuxièmement, Base64URL (RFC 4648 §5) remplace '+' et '/' par '-' et '_' et supprime le remplissage, car '+' et '/' ont une signification URL et '=' termine les chaînes de requête. JWT (RFC 7519) et JWS (RFC 7515) exigent Base64URL pour cette raison. Base64 est un encodage, pas un chiffrement — la forme encodée n'a aucune confidentialité, et l'alphabet est si court que n'importe quel observateur lit le résultat trivialement. Confondre Base64 avec un mécanisme de sécurité est un schéma récurrent de CVE : CVE-2004-2761 documentait la collision à préfixe choisi MD5 sur les signatures de certificats X.509 qui permettait de forger des certificats, tandis que CVE-2005-4900 et d'autres impliquaient l'ancienne pratique des hachages de mot de passe md5crypt `$1$` recodés ou re-hachés par une couche d'authentification confondant les octets décodés Base64 avec de nouvelles identités. Le schéma récurrent est le même : un système traite l'encodage comme s'il ajoutait une couche de confidentialité qu'il n'offre pas, et le résultat est exploitable. Pour de vrais secrets, utilisez AES-GCM (RFC 5288) ou ChaCha20-Poly1305 (RFC 8439). Pour la compression puis Base64 (ce que fait `gzip -b64`), notez que la forme encodée fait environ 1,37× la taille compressée, et toute modification d'octet dans le flux compressé casse le décodage — Base64 est donc une mauvaise couche d'intégrité ; un HMAC-SHA256 sur les octets avant encodage est l'approche correcte.
- Le RFC 4648 (octobre 2006) définit Base64, Base32 et Base16 avec un alphabet canonique (A-Z, a-z, 0-9, +, /) et '=' comme caractère de remplissage. La variante MIME (RFC 2045) insère des retours à la ligne tous les 76 caractères pour le transport ; la variante URL-safe (Base64URL, RFC 4648 §5) remplace + et / par - et _ et supprime le remplissage — utilisée par JWT (RFC 7519), JWS (RFC 7515) et JWK (RFC 7517).
- Mécanisme : 3 octets d'entrée (24 bits) → 4 caractères de sortie (6 bits chacun). La surcharge est de 33,3% — chaque Mo de données binaires devient 1,33 Mo en Base64. Pour l'ASCII, le ratio peut être encore pire lorsque l'entrée contient '=' ou d'autres caractères échappés par les protocoles environnants.
- Règle de remplissage : longueur d'entrée mod 3 = 0 → aucun remplissage ; mod 3 = 1 → « == » (deux caractères de remplissage, un octet encodé) ; mod 3 = 2 → « = » (un caractère de remplissage, deux octets encodés). '=' ne porte aucune information ; il indique simplement au décodeur combien d'octets ont été supprimés.
- Piège UTF-8 + btoa : `btoa('é')` lance une InvalidCharacterError car btoa traite l'entrée comme des unités de code Latin-1. La page contourne ce problème en encodant via `TextEncoder` (UTF-8) avant btoa, et en décodant via `TextDecoder` après atob. Sans cette étape, tout ce qui est en dehors de U+0000..U+00FF devient « 0 octet encodé » au lieu d'une erreur.
- Base64URL est requis pour JWT, JWS et JWK (RFC 7519/7515/7517). Il utilise '-' et '_' au lieu de '+' et '/' (caractères significatifs en URL) et supprime le remplissage '=' (qui termine les chaînes de requête). Passer un segment d'en-tête JWT à un décodeur Base64 au lieu d'un décodeur Base64URL renvoie du contenu invalide ; la page ne détecte pas automatiquement — choisissez la variante adaptée à la charge utile.
- Performance : l'encodage atteint environ 400-700 Mo/s dans V8 sur un ordinateur portable moderne (une boucle serrée de recherches dans une table et de décalages de bits). Le décodage est à une vitesse similaire. Pour les gros blobs (10+ Mo), le goulot d'étranglement est l'allocation, pas le calcul — le tampon de sortie est 33% plus grand et `TextEncoder/TextDecoder` effectue une copie.
- Base64 est un encodage, pas un chiffrement — quiconque possède la chaîne peut la lire. CVE-2004-2761 (collision à préfixe choisi MD5 sur les signatures de certificats X.509) et de nombreux writeups MISC-CTF utilisent cette idée fausse comme premier tremplin. Pour des secrets, utilisez AES-GCM (RFC 5288) ou ChaCha20-Poly1305 (RFC 8439). Pour les URI data:, attention à la taille encodée : une image de 10 Mo devient une URL de 13,3 Mo, ce qui dépasse la plupart des limites de longueur d'URL des navigateurs et des limites de taille des emails.
- Note de migration : Base16 (hexadécimal) est préféré dans les protocoles bas niveau et la sortie de hachage car chaque octet correspond exactement à 2 caractères et la longueur est prévisible (pas de calcul de remplissage). Base32 est préféré pour la transcription humaine (pas de caractères similaires). Base64 est le standard universel pour le transport binaire dans les protocoles textuels mais est progressivement remplacé par les octets bruts sur HTTP/2 et WebTransport lorsque le cadrage le permet.
Exemples
Encoder du texte ASCII
Entrée : Hello
Sortie : SGVsbG8= (5 octets -> 8 caractères, 1 caractère de remplissage)
Entrée : Hello, World!
Sortie : SGVsbG8sIFdvcmxkIQ== (13 octets -> 18 caractères, 1 caractère de remplissage)
Entrée : Man
Sortie : TWFu (3 octets -> 4 caractères, sans remplissage)
L'exemple « Man » est le vecteur canonique RFC 4648 : les octets 0x4D 0x61 0x6E
s'assemblent en la valeur 24 bits 0x4D616E, sont divisés en blocs de 6 bits 0x0D 0x16
0x0E 0x0A, et mappés sur T W F u via l'alphabet standard.Encoder du texte UTF-8 (chinois)
Entrée : ni hao (3 octets ASCII)
Sortie : 5L2g5aW9 (8 caractères)
Entrée : ni hao shi jie (4 caractères CJK, 12 octets UTF-8)
Sortie : 5L2g5aW95LiW55WM (16 caractères)
Chaque caractère CJK s'étend sur 3 octets UTF-8 (E4 BD A0 etc.), donc
la sortie Base64 croît d'environ 4/3 puis d'environ 4/3 à nouveau - environ 2,67x
le nombre de caractères dans la sortie encodée. La page passe d'abord par
TextEncoder().encode(str) pour éviter le piège btoa('InvalidCharacterError')
sur une entrée non ASCII.Décoder et faire un aller-retour sur un segment JWT
Encodé : eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Décodé : {"alg":"HS256","typ":"JWT"}
Aller-retour :
encode('{"alg":"HS256","typ":"JWT"}') -> eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
decode('eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9') -> {"alg":"HS256","typ":"JWT"}
Les segments JWT utilisent Base64URL, donc la page doit accepter '-' / '_'
en plus des '+' / '/' standard. Un en-tête JWT passé à un décodeur Base64
strict renvoie des données corrompues - choisissez la bonne variante pour
la charge utile.Base64 vs Base64URL
Entrée : Hello><h2>
Standard : SGVsbG8+PGgyPg== (remplissage + / = ; sûr dans JSON / e-mail)
URL-safe : SGVsbG8-PGIyPg (- _ sans remplissage ; sûr dans les chemins/queries d'URL)
Différences :
'+' (62) -> '-' et '/' (63) -> '_'
le remplissage '=' est entièrement supprimé en forme URL-safe
Utilisez Base64URL pour JWT, JWS, JWK, et tout jeton qui transite dans
une query string d'URL, car '+' / '/' sont significatifs en URL et '='
termine la query.FAQ
Le Base64 est-il du chiffrement ?
Non. Base64 est un encodage, pas un chiffrement. Il convertit simplement des octets arbitraires en 64 caractères ASCII imprimables (A-Z, a-z, 0-9, +, /) afin qu'ils survivent aux systèmes qui altèrent les données binaires. Quiconque possède la chaîne encodée peut la décoder instantanément : aucun secret n'intervient.
Pourquoi ma sortie encodée se termine-t-elle par un ou deux signes = ?
Base64 produit 4 caractères en sortie pour 3 octets en entrée. Lorsque la longueur d'entrée n'est pas un multiple de 3, l'encodeur complète avec des = pour que la longueur du résultat reste un multiple de 4. Un octet d'entrée restant → deux = ; deux octets restants → un = ; entrée alignée → aucun. Certaines implémentations omettent le padding, ce qui est légal mais pas universellement interopérable.
Qu'est-ce que le Base64 « URL-safe » ?
Le Base64 standard inclut / et + qui ont une signification particulière dans les URL et les noms de fichiers. Le Base64 URL-safe (RFC 4648 §5) les remplace par _ et - et omet souvent le padding =. Utilisez-le pour les jetons JWT, les paramètres d'URL et les noms de fichiers ; utilisez le Base64 standard partout ailleurs.
Pourquoi la chaîne Base64 est-elle ~33 % plus longue que l'original ?
Chaque tranche de 6 bits d'entrée devient un caractère de sortie de 8 bits, donc taille_encodée = ceil(longueur_entrée / 3) * 4. C'est environ 4/3 de l'entrée (33 % de surcoût). C'est le prix à payer pour représenter des octets arbitraires en ASCII imprimable.
Quels formats d'entrée puis-je coller ici ?
Pour l'encodage, collez du texte brut (encodé en UTF-8 sous le capot) ou téléversez un fichier. Pour le décodage, collez une chaîne Base64 avec ou sans espaces : le décodeur supprime automatiquement les sauts de ligne. Si le décodage échoue, vérifiez la présence de caractères parasites ou d'un = de padding manquant.
Le Base64 peut-il transporter du contenu de fichier binaire ?
Oui. C'est son cas d'usage principal : les images intégrées en HTML/CSS (URL data:), les pièces jointes d'e-mail (MIME) et les identifiants dans les en-têtes HTTP (Basic Auth) utilisent tous Base64 pour faire passer du contenu binaire dans des canaux uniquement textuels. Sachez que la charge utile résultante est 33 % plus volumineuse que le fichier brut.
Devrais-je utiliser Base64 pour cacher des données sensibles ?
Jamais. Base64 est entièrement réversible sans clé. Le considérer comme une obfuscation est une erreur fréquente qui a déjà fait fuiter mots de passe et jetons dans de nombreux incidents réels. Utilisez un véritable chiffrement ou un gestionnaire de secrets pour tout ce qui est sensible.