Base64 : encoder et décoder texte, fichiers et images en ligne

L'encodeur est un scalpel pour une chaîne que vous pouvez coller, pas un CDN.

Si la réponse dépend d'un fichier que le navigateur ne devrait pas tenir, ou de la crypto, restez en CI ou dans un gestionnaire de secrets.

Quiconque peut lire la chaîne peut la décoder. Base64 n'a ni clé, ni contrôle d'intégrité, ni confidentialité. Un jeton qui paraît opaque dans un journal reste du texte clair après un seul décodage. Si les octets doivent rester secrets, chiffrez-les (ou ne les mettez pas dans le payload). S'ils doivent rester authentiques, signez-les avec un HMAC ou une signature JWT, pas avec Base64 lui-même.

La RFC 4648 définit deux alphabets. Le Base64 standard utilise + et / ; il garde en général le padding =. Le Base64 URL-safe (JWT, cookies, chemins) utilise - et _ ; il omet en général le padding. L'option URL-safe de FastMinify effectue les deux substitutions et retire le padding à l'encodage. Au décodage, le mode URL-safe rétablit l'alphabet standard et restaure le padding, tandis que le mode standard transmet la chaîne telle quelle à atob : atob tolère un padding manquant, mais refuse - et _. Une chaîne URL-safe avec l'option désactivée donne donc une erreur d'entrée invalide, alors qu'une chaîne standard avec l'option activée est décodée quand même, car seuls ces deux caractères sont remplacés.

Un JWT compact est formé de trois segments Base64URL séparés par des points, écrits header.payload.signature. Les points ne sont pas du Base64. L'outil Base64 décode une chaîne d'alphabet, pas un jeton à points. Son message d'erreur le dit : collez seulement les caractères encodés, sans points. Pour un JWT, copiez chaque partie entre les points, ou ouvrez le décodeur JWT et inspectez l'en-tête et le payload en une seule étape.

Base64 gonfle les données binaires d'environ 33 % (3 octets deviennent 4 caractères ASCII). Un JPEG de 200 Kio devient environ 267 Kio de CSS. L'image ne peut alors plus être mise en cache séparément de la feuille de style, et elle alourdit une feuille qui bloque déjà l'affichage. Avec HTTP/2, les requêtes supplémentaires coûtent peu, ce qui retire la principale raison d'intégrer. Les data URI se justifient pour de minuscules icônes qui coûteraient sinon une requête. Elles perdent pour les images d'en-tête, les photos de produit et tout ce que vous minifiez déjà comme fichier.

Les octets ne changent pas, seule l'écriture change. Le Base64 standard est la forme que produisent le MIME des e-mails et la plupart des API. Le Base64 URL-safe est celle qu'exigent les JWT, les cookies signés et les segments de chemin, pour que + et / n'entrent pas en conflit avec la syntaxe des requêtes. Une data URI est du Base64 standard précédé du préfixe data:<mime>;base64,, ce qui permet à un navigateur de traiter la chaîne comme une ressource.

Trois outils, trois entrées. L'encodeur texte applique UTF-8 puis Base64 à une chaîne, collée ou lue dans un fichier texte. Il n'interprète pas un PNG comme des pixels. Le convertisseur image lit les octets du fichier et vérifie le type MIME. PNG, JPEG, GIF, WebP et SVG sont acceptés, et un type MIME vide est refusé au lieu d'être deviné. Il plafonne les fichiers à 32 Mio et produit une data URI ou du Base64 brut. L'aperçu passe uniquement par un élément img : le SVG n'est jamais injecté dans le DOM comme balisage. Pour un SVG utilisé en CSS, avec le choix entre utf-8 et Base64 et un extrait CSS dédié, utilisez SVG vers data URI sur le hub SVG. Son entrée SVG est limitée à 512 Kio, une limite différente pour un autre usage.

On les confond parce qu'ils « rendent une chaîne plus sûre ». Ils résolvent pourtant des problèmes distincts. URL encode applique l'encodage en pourcentage aux caractères réservés des URI. Les entités HTML échappent le balisage pour qu'une chaîne tienne dans un attribut. Un hash (SHA-256, HMAC) offre une intégrité ou une authenticité à sens unique ; consultez les outils hash et HMAC du hub d'encodage, pas cet article. Base64 ne change que la façon d'écrire les octets.

Base64 prend 24 bits (3 octets) et les écrit sous forme de 4 caractères d'un alphabet de 64 symboles. C'est pourquoi la sortie est plus longue : 4/3, soit environ 33 % de plus, avec du padding si la longueur d'entrée n'est pas un multiple de 3. Ce surcoût est le prix d'un alphabet qui survit à l'e-mail, aux chaînes JSON et au CSS. C'est l'inverse de la minification. Si le payload est du JSON livré en HTTP, minifiez d'abord le JSON, puis n'encodez que si une couche d'enveloppe exige de l'ASCII ; voir le guide de minification JSON.

Le btoa natif de JavaScript opère sur une chaîne binaire (valeurs 0–255). Passez-lui café et il encode sans prévenir l'unique octet Latin-1 de é au lieu des deux octets UTF-8 ; passez-lui un emoji ou un caractère CJK et il lève une exception. FastMinify encode les octets UTF-8 avec TextEncoder, puis Base64, selon le même contrat que Node Buffer.from(text, 'utf8').toString('base64'). Le décodage fait l'inverse avec TextDecoder. Les emoji et le CJK survivent. Si vous décodez un blob qui n'a jamais été du texte UTF-8 (un PNG, un flux gzip), vous obtenez des caractères de remplacement, pas un fichier. Ce blob relève d'image-to-base64 ou d'un dump hex, pas d'un champ texte.

Quand la longueur en octets n'est pas un multiple de 3, le Base64 standard ajoute = ou == pour que la longueur de la chaîne soit un multiple de 4. Les contextes URL-safe (JWT, certains cookies) omettent ce padding parce que = est un délimiteur de requête. L'encodage URL-safe de FastMinify le retire ; le décodage URL-safe le remet avant atob. Le décodage standard s'en passe, car atob tolère un padding manquant. Exemples classiques de la RFC : f → Zg==, fo → Zm8=, foo → Zm9v.

Ouvrez l'encodeur/décodeur Base64. Collez le texte ou choisissez un fichier texte (la limite côté navigateur est de 32 Mio, comme pour les autres sélections de fichiers du site). Choisissez Encoder ou Décoder. Laissez l'option Base64 compatible URL (URL-safe) désactivée pour le MIME, les payloads de data URI et la plupart des exemples d'API. Activez-la pour les segments JWT, les valeurs de cookies signés et tout ce qui ira dans un chemin. Chargez l'exemple si vous voulez seulement voir comment l'outil fonctionne. Tout reste dans l'onglet.

Ouvrez l'outil image vers Base64. Choisissez une image (PNG, JPEG, GIF, WebP ou SVG, jusqu'à 32 Mio) ou déposez-la sur la page. Sélectionnez Data URI pour url() en CSS et img src, ou Base64 brut pour passer le résultat à un autre outil. L'aperçu passe par un élément img, et le SVG n'est pas monté dans le DOM. Les types MIME vides ou non pris en charge sont refusés, car l'outil ne devine pas. Après une icône minuscule, vous pouvez coller l'URI dans le CSS. Après une photographie, ce n'est en général pas recommandé.

L'encodage n'est souvent qu'une étape d'une session de débogage plus longue. Le hub d'encodage réunit les outils voisins.

Si la chaîne vit déjà dans un script, le Buffer de Node suit le même chemin UTF-8 puis Base64 que FastMinify. Utilisez base64url quand le consommateur est une bibliothèque JWT.

Le couple natif btoa / atob est une API de chaîne binaire. Enveloppez-le avec TextEncoder/TextDecoder, sinon tout ce qui sort du Latin-1 sera corrompu. C'est exactement l'enveloppe que l'outil texte FastMinify applique déjà.

Un PEM local, une fixture binaire, ou un job CI qui ne doit pas ouvrir un navigateur : openssl reste le bon outil. FastMinify ne remplace pas un pipeline qui calcule déjà des hash ou signe des fichiers sur disque.

Pas d'installation, rien n'est envoyé, du texte UTF-8 plus un convertisseur d'images dédié avec un plafond de 32 Mio et une option URL-safe. Les limites : l'outil texte n'est pas un encodeur de fichiers binaires, HEIC et PDF sont hors périmètre de l'outil image, et la vérification JWT est une autre page. Servez-vous-en pour inspecter, enseigner et dépanner une machine sans Node, puis gardez openssl ou Buffer en CI.