Encodage Base64 de fichiers en ligne, gratuit

D'où vient Base64, et pourquoi on l'utilise encore

Base64 a été conçu pour transporter des données binaires 8 bits à travers des canaux ASCII 7 bits. La première spécification formelle était la RFC 989 (février 1987) pour le courrier électronique amélioré pour la confidentialité (Privacy-Enhanced Mail). La RFC 1341 (juin 1992) et surtout la RFC 2045 « MIME Partie Un » (novembre 1996) en ont fait la façon standard d'attacher des fichiers binaires aux e-mails. Le document canonique actuel est la RFC 4648 (octobre 2006), qui a également défini la variante URL-safe. Le mécanisme est simple : prenez 3 octets d'entrée (24 bits), divisez en quatre groupes de 6 bits, recherchez chacun dans l'alphabet 64 caractères A-Z a-z 0-9 + /, ajoutez le rembourrage = pour que la longueur de sortie soit un multiple de 4. La taille de sortie est exactement 4 ÷ 3 ≈ 133 % de l'entrée. Pour l'intégration dans les URL (JWT, OAuth, URL pré-signées S3), la variante URL-safe de la RFC 4648 §5 substitue - à + et _ à / ; le rembourrage est généralement omis.

L'URL data: : Base64 dans vos HTML et CSS

Le schéma d'URL data: a été spécifié dans la RFC 2397 (août 1998). Format : data:[<mediatype>][;base64],<data>. Exemple : <img src="data:image/png;base64,iVBORw0KGgo..."> intègre un PNG en ligne sans requête HTTP supplémentaire. Le WHATWG URL Living Standard régit l'interprétation moderne des navigateurs de ces URL et le HTML Living Standard confirme qu'elles sont valides partout où une URL est autorisée, y compris <img>, <link>, <iframe>, et la fonction CSS url(). Conseil pratique : utilisez des URL data pour les assets inférieurs à environ 4 Ko, où économiser une requête HTTP l'emporte sur les 33 % de surcharge de charge utile. Au-dessus de 10 Ko, les références de fichiers régulières avec mise en cache du navigateur l'emportent presque toujours, surtout sur le multiplexage HTTP/2.

Les API du navigateur qui alimentent cet outil

Cette page utilise l'API FileReader du HTML Living Standard (à l'origine la W3C File API First Public Working Draft de novembre 2009 ; livrée dans Chrome 13 / Firefox 3.6 / Safari 6 / Internet Explorer 10). FileReader.readAsDataURL(blob) renvoie la chaîne complète data:<mime>;base64,<...> en un seul appel. L'alternative héritée est btoa() (nommée d'après l'historique commande Unix « binary-to-ASCII » et un vestige de JavaScript DOM Level 0), mais elle lance une erreur sur les entrées non-Latin-1 sauf si vous transcodez d'abord via UTF-8. Le remplacement moderne est Uint8Array.prototype.toBase64(), ajouté à ECMAScript 2025 au TC39 Stage 4. Il a été livré dans Chrome 132 (janvier 2025), Firefox 133 (novembre 2024), et Safari 18.2 (décembre 2024). Utilisez la nouvelle API pour tout nouveau code ; réservez btoa pour la compatibilité avec les navigateurs plus anciens.

Où va vraiment la sortie de cet outil

• Icônes et petites images en ligne dans HTML / CSS pour des documents autonomes ou orientés hors-ligne.
• Charges utiles de téléchargement de fichiers JSON quand le backend attend une chaîne Base64 dans un champ JSON plutôt que multipart/form-data.
• Pièces jointes de courriel MIME : la RFC 2045 exige Base64 (ou quoted-printable) pour tout corps non-7 bits, ce qui signifie chaque pièce jointe PDF, image ou document.
• Jetons JWT / OAuth : chaque JWT est composé de trois segments Base64 URL-safe joints par ..
• Fixtures de test commits dans git, pour que les images de test / documents d'exemple voyagent avec le fichier de test.
• Charges utiles Web Push lors de la livraison d'un blob binaire via l'API Push.
• Polices web sur le chemin critique intégrées dans le CSS pour éviter le FOIT (flash de texte invisible) au premier rendu, compromis accepté.

Erreurs courantes

• Traiter Base64 comme du chiffrement. Base64 est un encodage, pas de la sécurité. Toute personne ayant la chaîne peut la décoder dans son navigateur. N'utilisez jamais Base64 pour « cacher » des informations d'identification, clés API ou PII.
• Oublier le préfixe data:<mime>;base64,. Une chaîne Base64 nue n'est pas une URL data. Un <img> a besoin de la forme complète data:image/png;base64,<votre-base64> pour s'afficher.
• Mélanger Base64 URL-safe et standard. JWT et URL pré-signées S3 utilisent URL-safe (- et _). Coller du Base64 standard (+ et /) dans ces contextes produit des échecs de décodage silencieux.
• Oublier la directive CSP data:. Une page avec img-src 'self' dans sa Content Security Policy refusera de charger toute URL data:image/.... Vous devez explicitement autoriser img-src 'self' data: (et de même pour font-src, media-src, etc.).
• Encoder des fichiers de 100 Mo de manière synchrone sur le thread principal. FileReader.readAsDataURL bloque l'UI pendant plusieurs secondes sur un fichier de 200 Mo. Pour tout dépassant ~20 Mo, utilisez un Web Worker ou des morceaux en streaming.
• Appeler btoa("é") directement. Cela lance InvalidCharacterError parce que btoa attend du Latin-1, pas de l'UTF-8. Utilisez soit btoa(unescape(encodeURIComponent(text))) (hérité), soit passez un Uint8Array via la méthode moderne toBase64().
• Incorporer un logo de 500 Ko comme URL data. La surcharge de 33 % plus la perte de la mise en cache du navigateur signifie que chaque chargement de page télécharge 665 Ko au lieu de 500 Ko-une-fois. Utilisez une référence d'asset régulière.

Plus de questions fréquentes

Quelle est la surcharge exacte de taille de Base64 ?

Exactement 4 ÷ 3 ≈ 1,333× l'entrée, plus 1-2 octets de remplissage =. Une entrée de 999 octets devient 1332 caractères de Base64 (pas de remplissage parce que 999 ÷ 3 = 333 exactement). Une entrée de 1000 octets devient 1336 (un octet de remplissage). Pour une URL data, ajoutez les octets du préfixe (par exemple data:image/png;base64, fait 23 caractères).

Comment obtenir du Base64 URL-safe pour JWT ou URL pré-signées S3 ?

Prenez la sortie Base64 standard de cet outil et appliquez deux remplacements : + → -, / → _. JWT supprime spécifiquement le remplissage = final ; S3 le conserve. La RFC 4648 §5 documente la variante.

Puis-je faire un aller-retour d'un fichier à travers Base64 sans corruption ?

Oui. Base64 est un encodage sans perte. Encoder en Base64 puis décoder en arrière produit un original identique octet par octet. La seule façon de perdre des données est de tronquer la chaîne Base64 (par exemple en limitant les caractères de votre stockage) ou de confondre les alphabets standard vs URL-safe lors du décodage.

Quelle est la taille maximale de fichier que cet outil peut gérer ?

Pas de limite stricte ; en pratique, la mémoire du navigateur est le plafond. Encoder un fichier de 100 Mo nécessite environ 100 Mo d'entrée plus 133 Mo de sortie, plus la surcharge DOM pour la chaîne de résultat, peut-être 400 Mo au total. Sur mobile, attendez-vous à des échecs au-dessus d'environ 30 Mo. L'encodage s'exécute sur le thread principal, donc l'UI se fige pendant le traitement ; pour les fichiers de plus de 20 Mo, une solution côté serveur ou Web Worker est plus confortable.

Mon fichier est-il téléchargé quelque part ?

Non. Le fichier est lu avec l'API FileReader.readAsDataURL du navigateur, qui s'exécute entièrement dans votre navigateur. Aucune requête réseau n'est faite et aucune copie de votre fichier n'est stockée sur un serveur. Ouvrez l'onglet Réseau dans DevTools et déposez un fichier : vous verrez zéro requête sortante pendant l'encodage.