Encodage/Décodage Base64
Encodage/Décodage Base64
Encodage/Décodage Base64: Prend en charge l'encodage et le décodage Base64 de données textuelles et binaires avec des options de format URL-safe et MIME. Prend en charge l'analyse des URL de données, l'encodage ligne par ligne et la reconnaissance automatique de format, adapté aux appels d'API, aux pièces jointes d'e-mails et à l'intégration de données.
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é
Image upload
Keep the original bytes and switch between Data URL and raw Base64 output without re-uploading
Image Data URL
Paste data:image/...;base64,... to auto-detect MIME and rebuild a previewable image
Raw Base64 image data
Supply the original image MIME explicitly before reconstructing or downloading
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é
Gestion de session
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