Que signifient « encoder » et « decoder » en Base64 ?
Encoder en Base64 (« encode base64 ») transforme des octets — le plus souvent les octets d'un texte encodé en UTF-8 — en une chaîne de 64 caractères autorisés : les 26 lettres en majuscules, les 26 lettres en minuscules, les 10 chiffres, puis + et /. Decoder du Base64 (« decode base64 ») effectue exactement l'opération inverse : la chaîne est lue par paquets de 4 caractères, chaque caractère repère 6 bits, et 24 bits donnent 3 octets. C'est ce aller-retour que la plupart des gens cherchent quand ils tapent « encode and decode base64 ».
Base64 n'est ni une compression ni un chiffrement : le texte devient environ un tiers plus long, et n'importe qui peut le lire en une seconde. Son intérêt est de transporter des octets sur des canaux qui n'acceptent que des caractères ASCII sûrs — URL, en-têtes HTTP, fichiers de configuration, JSON, SVG inline, e-mails, bases de données textuelles.
Comment encoder du texte en Base64
Étape 1 : le texte est d'abord codé en octets selon le jeu de caractères choisi — UTF-8 par défaut, mais Latin-1, Windows-1252, ASCII ou UTF-16 restent utiles pour du legacy. Étape 2 : les octets sont lus trois par trois, soit 24 bits. Étape 3 : ces 24 bits sont découpés en quatre blocs de 6 bits, et chaque bloc est remplacé par le caractère de position correspondant dans l'alphabet. Étape 4 : si le dernier groupe est incomplet, il est complété par des bits à zéro et la chaîne est fermée par un ou deux = (le padding).
Exemple pas à pas : « AB » vaut 65 puis 66 en décimal, soit 01000001 01000010. En trois octets avec complément : 01000001 01000010 00000000. Les quatre groupes de 6 bits sont 010000 010100 001000 000000 → positions 16, 20, 8, 0 → QUI=. Tapez simplement « AB » dans l'encodeur : le résultat apparaît avant même de relâcher la touche.
Comment decoder du Base64 en texte
Le décodage lit la chaîne par groupes de 4 caractères après avoir retiré les retours à la ligne et les espaces éventuels. Chaque caractère est remplacé par sa valeur sur 6 bits, les quatre valeurs sont concatenées en 24 bits, puis les 24 bits sont découpés en 3 octets. Les = finaux signalent combien d'octets réellement utiles contient le dernier groupe : un = signifie 2 octets, deux = signifient 1 octet.
Si la chaîne contient - ou _, il s'agit de la variante URL-safe : l'outil les convertit automatiquement en + et / avant le décodage. Si le padding manque, le bouton « Corriger le padding » le rétablit. En cas de caractère hors alphabet, d'onglet mal placé ou de longueur non multiple de 4, l'erreur est affichée avec la raison exacte plutôt qu'un simple « invalide ».
Variante URL-safe (RFC 4648 §5)
Le Base64 standard utilise + et /, deux caractères qui posent problème dans une URL : le + est interprété comme un espace par la plupart des serveurs, et le / peut être confondu avec un séparateur de chemin. La variante URL-safe les remplace par - et _, qui ne nécessitent aucun échappement. Elle est obligatoire dans les JWT (les trois segments d'un jeton sont encodés sans padding), les cookies, les identifiants et les paramètres d'URL.
Padding « = » : à quoi ça sert
Le Base64 travaille par groupes de 4 caractères, mais la taille d'un fichier n'est presque jamais multiple de 3 octets. Le padding rétablit la longueur attendue : 1 octet restant donne ==, 2 octets restants donnent =. Certains systèmes le suppriment (certaines API, Base64URL) ; d'autres le réclament (PHP, d'anciens décodeurs). L'option « Sans padding » de l'encodeur et le bouton « Corriger le padding » du décodeur couvrent les deux cas.
Encodage des caractères : UTF-8, Latin-1, UTF-16
Base64 ne connaît pas les caractères, seulement des octets. La question cruciale est donc : par quoi encode-t-on le texte avant le Base64 ? En UTF-8, « é » fait 2 octets et « 日 » en fait 3 ; en Latin-1, « é » tient en 1 octet mais « 日 » devient impossible. Un décodage UTF-8 d'une chaîne encodée en Latin-1 produit des caractères aberrants (« mojibake »). Si vous interrogez un outil en ligne et que le résultat est incompréhensible, c'est presque toujours l'encodage de départ qui est différent — d'où les six options proposées ici.
Fichier, data URI et images en Base64
Une data URI a la forme data:<type MIME>;base64,<données>. Elle permet d'embarquer directement une image dans du CSS, du HTML ou du JSON : background-image:url(data:image/png;base64,iVBOR…). Pour décoder, collez la chaîne entière dans l'onglet « Fichier ⇄ Base64 » : le type MIME est extrait, le nom proposé, puis le fichier est régénéré et téléchargeable. Attention à la taille : le Base64 ajoute environ 33 % et une data URI n'est jamais mise en cache séparément.
Base64, URL-encoding et pourquoi ne pas les confondre
Le percent-encoding (%20, %C3%A9) remplace chaque octet non autorisé par un pourcentage : il est deux à trois fois plus long que le Base64 mais préserve le texte original à l'œil. Le Base64 produit une chaîne compacte et régulière, parfaite pour les blobs, mais illisible. L'onglet « URL & data URI » propose les deux conversions côte à côte pour éviter l'erreur classique d'encoder une URL en Base64 quand il fallait l'échapper — ou l'inverse.
Base64 dans les formats du quotidien
Le Base64 est partout : les trois segments d'un JWT, l'attribut src d'une image SVG inline, le champ cert d'un PDF, les attachments MIME des e-mails (RFC 2045), les Authorization: Basic des API (utilisateur:motdepasse), les fichiers .pem et les clés SSH, le contenu des .docx et .xlsx (ZIP), les avatars dans le stockage client, et les data- attributes des tests automatisés. Savoir encoder et decoder rapidement évite d'ouvrir un terminal pour une seule chaîne.
Ce que Base64 n'est pas
Base64 ne chiffre rien : une chaîne encodée se déchiffre en une ligne de code. Ne l'utilisez jamais comme protection de mot de passe, de clé API ou de données personnelles. Ce n'est pas non plus de la compression : prévoyez toujours 33 % de volume supplémentaire. Enfin, Base64 n'est pas adapté au binaire compressé déjà dense (PNG, ZIP) au-delà de quelques mégaoctets, où le coût mémoire devient pénalisant.
Performances et bonnes pratiques
Dans le navigateur, TextEncoder et TextDecoder traitent plusieurs mégaoctets par seconde ; l'algorithme Base64 lui-même est linéaire, sans récursion ni allocation par caractère. Les fichiers de plus de 5 Mo peuvent ralentir l'interface : pour des lots plus volumineux, préférez un traitement en Web Worker ou côté serveur. Conservez toujours l'encodage d'origine documenté à côté de la chaîne, et testez le round-trip (encoder puis decoder) avant de stocker un résultat en base de données.
Recommandé pour
Développeurs back-end et front-end (tokens, data URI, headers HTTP), intégrateurs et rédacteurs techniques (SVG inline, images de fond), administrateurs système et DevOps (certificats, clés, dumps), testeurs et pentesteurs (Authorization Basic, fuzzing de paramètres), étudiants (comprendre les octets, l'ASCII et l'UTF-8), et toute personne qui a besoin d'un encodeur décodeur Base64 en ligne rapide, complet et confidentiel.
Français
English
Español
Deutsch
Português
中文
हिन्दी
العربية
Русский
Bahasa Indonesia
日本語
Italiano
Türkçe
한국어
Nederlands
Polski
Tiếng Việt