Encodage/Décodage Base64
Encodage/Décodage Base64
Encodage/Décodage Base64 prend en charge les modes texte et image, encode et décode le texte UTF-8, génère des Data URL ou du Base64 brut à partir d’images et reconstruit localement l’aperçu et le téléchargement.
Démarrage rapide
Scénarios courants
URL/JWT
privilégier la variante URL‑safe (−/_); le « = » final peut être omis pour éviter l’échappement
E‑mail/MIME
lorsqu’un retour à la ligne est requis, utiliser 76 colonnes MIME (CRLF) ; pour le Web, éviter les retours. Cet outil propose un retour à 76 colonnes et un commutateur LF/CRLF
Texte multiligne
activer l’encodage par ligne pour encoder chaque ligne séparément
MIME/PEM
activer le retour 76 colonnes ; activer LF si nécessaire
Data URL
pour l’intégration, générer data:[mime];base64,… ; le décodeur extrait automatiquement après la virgule
Vérification aller‑retour
encoder puis décoder immédiatement pour vérifier l’intégrité
Téléversement d’image
conservez les octets d’origine et basculez entre Data URL et Base64 brute sans renvoyer le fichier
Data URL d’image
collez data:image/...;base64,... pour détecter automatiquement le MIME et reconstruire une image prévisualisable
Données image en Base64 brute
indiquez explicitement le MIME d’origine avant de reconstruire l’aperçu ou de télécharger
Scénario complémentaire
encode base64, decode base64 et base64 convertisseur peuvent être pris en charge dans le même flux afin de vérifier le résultat avant copie ou export.
Paramètres d’encodage et variantes
Conseils d'utilisation
Limitations et compatibilité
Confidentialité et sécurité
FAQ
Base64 est un schéma permettant de représenter des données binaires sous forme de texte imprimable. Né dans la norme MIME des e‑mails (années 1990, RFC 1521/2045), il a été unifié par la RFC 4648. Le but n’est pas le « chiffrement », mais d’acheminer des octets de manière fiable sur des canaux textuels. Principe : chaque 3 octets (24 bits) sont découpés en quatre blocs de 6 bits et mappés sur 64 caractères A–Z, a–z, 0–9, +, /. Si la longueur n’est pas multiple de 3, le « = » aligne le résultat. La taille augmente d’environ 33 %. Variantes & choix : la RFC 4648 définit la variante URL‑safe (‑ et _ à la place de + et /) et l’omission possible des « = » finaux. Préférer URL‑safe pour URL/Cookie/JWT ; utiliser le Base64 standard (avec +/ et =) pour les outils hérités/MIME. Cet outil produit par défaut de l’URL‑safe, et le décodeur accepte les deux variantes. Exemples : ??? → standard Pz8/, URL‑safe Pz8_ ; ~~~ → standard fn5+, URL‑safe fn5‑. Data URL : pour l’embarqué, utiliser data:[mime];base64,… ; au décodage, extraire la partie après la virgule (géré automatiquement par cet outil). Repères (bref) : 1993 RFC 1521 (MIME v1, Ned Freed & Nathaniel Borenstein) → 1996 RFC 2045 (mise à jour MIME) → 2003 RFC 3548 (Simon Josefsson, abstrait Base16/32/64) → 2006 RFC 4648 (Simon Josefsson, unifie et définit Base64URL, remplace 3548). Également : 1993 RFC 1421 (PEM, J. Linn) utilise Radix‑64 (apparenté à Base64) pour transporter des binaires par mail. Sécurité : Base64 est un formatage réversible, pas une garantie de confidentialité/intégrité ; chiffrer d’abord, puis encoder.
Non. C’est un encodage, tout le monde peut décoder. Pour la confidentialité, chiffrer d’abord
Vérifiez que la chaîne ne contient que A–Z, a–z, 0–9, +, / et =, et que la longueur est correcte
Les différences viennent souvent des retours à la ligne, du maintien du remplissage '=' , de la variante URL‑safe (−/_) et des détails d’implémentation. Utilisez UTF‑8, désactivez les retours et décidez si vous utilisez URL‑safe et conservez le remplissage
Base64 représente 8 bits avec 6 bits ; l’augmentation d’environ 33 % est inhérente
Pris en charge en UTF‑8. Des données non textuelles peuvent apparaître « illisibles » une fois décodées