Base64 est suffisamment utile pour devenir un réflexe. Une image doit passer dans JSON? On l’encode. Un identifiant paraît trop lisible? On l’encode. Un fichier doit être stocké dans une colonne texte? On l’encode encore. Ce réflexe crée de la dette lorsque le vrai problème n’est pas la compatibilité avec un canal textuel. Base64 augmente la taille, complique le streaming, cache la structure et donne parfois une illusion de sécurité.

Évitez les gros fichiers dans JSON

Un fichier encodé en Base64 prend environ un tiers de place en plus. Dans un document JSON, il devient une énorme chaîne. Le serveur et le client peuvent garder plusieurs copies en mémoire: fichier original, chaîne Base64, JSON sérialisé, résultat décodé. Pour des fichiers lourds, ce modèle consomme inutilement mémoire et CPU.

Un upload binaire, multipart, un stockage objet avec URL temporaire ou un flux direct est souvent meilleur. JSON peut transporter les métadonnées pendant que les octets circulent par un canal conçu pour eux.

Base64 ne compresse pas

Si le but est de réduire la taille, Base64 va dans la mauvaise direction. Il peut arriver qu’une compression de transport réduise ensuite la chaîne, mais cela ne transforme pas Base64 en algorithme de compression. La bonne approche consiste à compresser les données d’origine, puis éventuellement à les encoder si le canal final l’exige.

Le contrat doit alors préciser l’ordre des opérations. “gzip puis Base64” n’est pas équivalent à “Base64 puis gzip” pour le consommateur qui doit reconstruire le contenu.

N’utilisez pas Base64 comme anonymisation

Une adresse e-mail, une clé API ou un identifiant client encodé en Base64 reste le même secret ou la même donnée personnelle. Les logs, URLs et captures d’écran qui contiennent cette chaîne exposent l’information à quiconque sait décoder. L’apparence opaque ne change pas le niveau de sensibilité.

Pour réduire l’exposition, il faut minimiser, masquer, tokeniser ou chiffrer. Base64 ne fait que changer l’écriture des octets.

Ne le stockez pas si un type binaire existe

Beaucoup de bases disposent de colonnes binaires ou de blobs. Les utiliser permet d’éviter l’expansion Base64 et de conserver une sémantique plus claire. Une colonne texte remplie de Base64 complique les index, les validations et les migrations.

Il existe des exceptions: export texte, compatibilité avec un système ancien, petite configuration. Mais le stockage canonique d’une application moderne devrait représenter les données selon leur nature réelle.

Ne cachez pas des données structurées dans un blob

Un champ Base64 peut devenir une façon de contourner le design d’API: on y met une structure entière, et le contrat officiel ne dit plus rien. Les clients ne peuvent pas valider partiellement, les outils ne peuvent pas inspecter et les migrations deviennent opaques.

Si les données ont des champs et des règles métier, exposez-les avec un schéma explicite. Base64 est utile pour transporter un petit payload binaire, pas pour éviter de nommer le modèle.

Ne l’utilisez pas pour du texte recherchable

Un texte converti en Base64 n’est plus utile pour la recherche, le tri, l’analyse ou la déduplication. Les moteurs ne voient plus les mots, seulement une représentation artificielle. Si le contenu est sémantiquement du texte, stockez-le en texte avec un encodage clair.

Base64 intervient quand le canal ne peut pas transporter les octets en sécurité. Il ne doit pas remplacer un modèle de données correctement typé.

Les endpoints doivent limiter la taille

Accepter du Base64 sans limite ouvre la porte à des charges importantes en mémoire. La validation doit contrôler la taille de la chaîne et la taille décodée. Elle doit aussi refuser les caractères non autorisés pour la variante choisie.

Des erreurs distinctes pour “format invalide”, “variante incorrecte” et “taille trop grande” aident les clients légitimes tout en gardant un comportement prévisible.

Les data URLs ne sont pas toujours un gain

Intégrer une petite icône en Base64 dans CSS peut économiser une requête. Intégrer des ressources plus grandes augmente HTML ou CSS, empêche le cache indépendant et complique les politiques de sécurité. Le navigateur doit recharger la ressource avec le document qui la contient.

Pour des images réutilisées, un fichier statique avec bons en-têtes de cache est souvent plus efficace et plus facile à surveiller.

Utilisez-le pour la bonne raison

Base64 est excellent lorsque le problème est réellement de transporter des octets dans un format texte: certificats, petits blobs, signatures, pièces jointes ou tokens. Il devient coûteux quand il sert à masquer, compresser, stocker par facilité ou éviter un protocole clair.

La lisibilité opérationnelle compte aussi

Une longue chaîne Base64 est difficile à comparer dans un ticket ou un log. Les outils internes devraient afficher taille décodée, type attendu, checksum éventuel et aperçu sûr plutôt que forcer un opérateur à décoder manuellement. Cela réduit les erreurs humaines sans exposer le contenu sensible.

Pour les ressources réutilisables, un identifiant et un stockage objet sont souvent plus faciles à exploiter qu’un champ Base64 géant qui circule partout.

Avant de l’utiliser, demandez si le canal accepte du binaire, si le contenu est gros, s’il doit être recherché, si le streaming compte et si quelqu’un le confond avec une protection. Cette vérification simple garde Base64 à sa place: un outil de compatibilité, pas une architecture.