Encodez n'importe quel texte en Base64 ou décodez une chaîne Base64 vers du texte. Utilisez la variante URL-safe si vous devez intégrer le résultat dans une URL ou un nom de fichier. La conversion se fait localement dans votre navigateur.
Le Base64 est un encodage binaire-vers-texte qui représente des octets arbitraires à l'aide de seulement 64 caractères ASCII imprimables : A-Z, a-z, 0-9, plus + et / (ou - et _ dans la variante URL-safe). C'est la façon standard d'intégrer des données binaires — images, certificats, blobs chiffrés — dans des formats texte comme JSON, XML, e-mail ou en-têtes HTTP.
L'encodage augmente la taille d'exactement 4/3 (33 %) : chaque tranche de trois octets en entrée devient quatre caractères en sortie. L'encodage est entièrement réversible, donc le décodage redonne les octets originaux à l'identique. La variante URL-safe remplace + et / par - et _ pour éviter de casser les règles d'encodage d'URL.
Cet outil ne gère que du texte pour l'instant. Le glisser-déposer de fichiers est dans la feuille de route. En attendant, collez le contenu du fichier (par ex. via xxd) ou utilisez un utilitaire de bureau comme base64.
Oui. L'entrée est d'abord encodée en octets UTF-8, puis ces octets sont encodés en Base64. Les emoji, accents et caractères CJK passent correctement par un aller-retour encoder + décoder.
Le Base64 standard utilise + et /, tous deux réservés dans les URLs. La variante URL-safe (RFC 4648 §5) les remplace par - et _, et supprime le padding = final. Utilisez cette variante pour les URLs, noms de fichiers ou segments JWT.
Le Base64 encode trois octets d'entrée en quatre caractères de sortie, donc le résultat est toujours ~33% plus gros. Ce surcoût est le prix de l'alphabet text-safe. Si la taille compte (gros attachements, limites de payload), le Base64 n'est pas le bon outil — compressez d'abord les données avec gzip ou zstd, ou envoyez les octets bruts via un canal capable de binaire.
Non. Le Base64 est un encodage, pas un chiffrement. N'importe qui peut le décoder instantanément sans clé — aucun secret n'est impliqué. Si vous avez besoin de confidentialité, utilisez un vrai chiffre (AES-GCM, ChaCha20-Poly1305) et n'encodez en Base64 le texte chiffré résultant que si vous devez l'intégrer dans du JSON ou une URL.
Là où le Base64 réapparaît dans le quotidien du dev web.
Les JWT sont trois blocs Base64URL séparés par des points. Collez le bloc du milieu pour décoder les claims et vérifier l'utilisateur, l'expiration ou les scopes.
Authorization: Basic <Base64(user:pass)> — collez le suffixe pour récupérer les identifiants séparés par deux-points, utile pour déboguer un service en amont.
Encodez un PNG ou SVG minuscule pour l'inliner directement en HTML ou CSS, économisant une requête HTTP au prix de ~33 % d'octets en plus.
Le JSON ne peut pas porter d'octets bruts. Encodez le blob en Base64, envoyez-le en string et décodez côté récepteur — courant pour l'upload de fichiers en API REST.
La bonne variante pour le bon usage.
+ et / sont réservés en URL et risqués en nom de fichier. La variante URL-safe (- et _, sans padding) évite les deux problèmes.
Le Base64 gonfle de 33 %. Si la taille compte, gzippez ou brotlissez d'abord, puis Base64 — la compression bat généralement le surcoût d'encodage.
Le Base64 est entièrement réversible sans clé. Ne l'utilisez jamais comme un secret de pauvre ; combinez-le à un vrai chiffre quand la confidentialité compte.
JWT et beaucoup de contextes URL-safe suppriment le padding final =. La plupart des décodeurs acceptent l'entrée avec ou sans, donc ne rejetez pas sur la longueur mod 4.