Aide technique
Pourquoi Base64 rend-il les fichiers plus gros ?
Base64 rend en général les données binaires plus grandes d’environ un tiers. Voir la structure 3 octets vers 4 caractères, le remplissage, le surcoût Data URL, et quand la taille en plus vaut le coup.
Base64 rend en général les données binaires plus grandes d’environ un tiers, car il représente chaque 3 octets de données binaires avec 4 caractères Base64 imprimables.
Si la longueur d’entrée n’est pas un multiple exact de 3, le Base64 standard avec remplissage peut ajouter des caractères =. La longueur encodée est 4 × ceil(n / 3), où n est la longueur d’origine en octets.
« Environ 33% » décrit les grandes entrées. Sur de toutes petites entrées, le pourcentage peut paraître bien plus élevé à cause du remplissage. Base64 n’est pas de la compression. Pour encodage versus chiffrement, voir [Base64 n’est pas du chiffrement : à quoi ça sert vraiment](/fr/story/base64-is-not-encryption).
Cet article explique pourquoi la sortie Base64 est plus grande que les octets d’origine. Ce n’est pas un guide de sécurité. Si vous avez besoin d’encodage versus chiffrement, utilisez Base64 n’est pas du chiffrement : à quoi ça sert vraiment.
Pourquoi Base64 a-t-il besoin de plus d’espace ?
3 octets font 24 bits. Base64 découpe ces 24 bits en 4 groupes de 6 bits. Chaque groupe correspond à un caractère Base64, donc 3 octets d’entrée deviennent 4 caractères de sortie. Stocké à 1 octet par caractère ASCII, cela fait 4 / 3 ≈ 1.333 — environ 33.3% d’augmentation.
- 3 octets (24 bits)
- Découper en 4 groupes de 6 bits
- Chaque groupe → un caractère Base64
- 4 caractères (souvent 4 octets de texte)
Un exemple simple et vérifiable
Ces encodages correspondent au Base64 standard avec remplissage.
Man
ManBase64
TWFuMan fait 3 octets UTF-8/ASCII. TWFu fait 4 caractères : 3 → 4.
Hello
HelloBase64
SGVsbG8=Hello fait 5 octets. SGVsbG8= fait 8 caractères, dont un =. Sur de petites données, le remplissage fait paraître le pourcentage plus grand que 33%.
Comment calcule-t-on la taille Base64 ?
Pour le Base64 standard avec remplissage, encodedLength = 4 × ceil(originalBytes / 3).
| Octets d’origine | Caractères Base64 |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 4 | 8 |
| 5 | 8 |
| 6 | 8 |
1 ou 2 octets produisent encore 4 caractères. Utilisez la formule, pas un 33% fixe.
Que signifie le remplissage « = » ?
Le signe = indique que le dernier bloc de 3 octets n’était pas plein. 1 octet d’entrée utilise deux caractères = ; 2 octets en utilisent un ; 3 octets n’en utilisent aucun. Le remplissage n’est pas du chiffrement ni une fonction de sécurité.
Base64URL utilise-t-il moins d’espace ?
Base64URL change + en - et / en _, et Encoder et décoder en Base64 omet les = de fin à l’encodage. Cela peut raccourcir la chaîne de ces caractères =. La structure 3 octets → 4 caractères reste, donc Base64URL n’est pas un format binaire plus économe en espace.
Pourquoi les toutes petites entrées peuvent-elles croître de plus de 33% ?
1 octet → 4 caractères, c’est une hausse de 300% en longueur. 2 octets → 4, c’est 100%. 3 octets → 4, c’est environ 33.3%. Quand n grandit, le remplissage compte moins et le surcoût s’approche d’environ 33%. Base64 n’est pas 33% plus grand dans tous les cas.
Pourquoi une Data URL Base64 est-elle encore plus grande ?
Une Data URL ajoute un préfixe tel que data:image/png;base64, avant la charge. Sur un tout petit fichier, ce préfixe peut dominer le pourcentage. Encoder et décoder en Base64 peut émettre du Base64 brut ou une Data URL ; la sortie Data URL utilise l’alphabet standard.
Base64 vs binaire : lequel est plus petit ?
Le binaire brut est plus économe en espace pour le transport et le stockage. Base64 est plus grand, mais sûr comme texte dans JSON, l’e-mail et d’autres chemins texte seul. C’est un encodage binaire vers texte, pas de la compression.
Est-ce que Base64 compresse les fichiers ?
Non. Base64 n’est pas un format de compression. Le texte encodé est en général plus grand que les octets d’origine. Si vous appliquez ensuite gzip ou Brotli à ce texte, une partie de la redondance peut diminuer — le résultat dépend des données et du compresseur. gzip n’élimine pas complètement le surcoût Base64.
Que se passe-t-il si on applique gzip au Base64 ?
La compression HTTP peut réduire certains motifs répétés dans le texte Base64. JPEG, PNG ou ZIP se compressent souvent mal même en octets bruts, et Base64-puis-gzip reste selon les cas. Il n’existe pas de pourcentage extra universel après gzip.
Faut-il stocker des fichiers en Base64 ?
Base64 peut loger du binaire dans un champ JSON, un petit asset en ligne, une API texte seul, un copier-coller ou une Data URL. Pour les gros fichiers, stockage, mémoire et taille de charge grandissent tous. Ce n’est pas « n’utilisez jamais Base64 pour des fichiers ».
Pourquoi Base64 est-il courant dans les API JSON ?
JSON n’a pas de type binaire brut natif, donc les API placent souvent les octets dans une chaîne Base64. Pour les gros fichiers, multipart/form-data, un stockage d’objets ou un envoi binaire direct peuvent mieux convenir. Aucun choix n’est toujours le meilleur.
Pourquoi Base64 est-il utilisé dans l’e-mail ?
MIME peut utiliser Base64 pour qu’une pièce jointe binaire voyage en caractères sûrs pour le texte. Le même surcoût de taille s’applique encore. C’est une représentation de transport, pas un fichier plus petit.
Quand la taille en plus vaut-elle le coup ?
La taille en plus peut valoir le coup quand le binaire doit tenir dans du texte, que la charge est petite, qu’une API exige Base64, ou que vous avez besoin d’une Data URL. Pour les gros médias, préférez le binaire brut quand le système le permet.
Quand faut-il éviter Base64 ?
Évitez-le pour les gros fichiers, une bande passante serrée, des transferts fréquents, ou quand un chemin binaire existe déjà — selon le cas, pas « Base64 est une mauvaise pratique ».
Longueurs Base64 avec remplissage à vérifier
Nombres d’octets d’origine et nombres de caractères Base64 standard avec remplissage :
| Octets d’origine | Caractères Base64 |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 10 | 16 |
| 100 | 136 |
| 1,000 | 1,336 |
Toutes les lignes suivent 4 × ceil(n / 3). Ce sont des nombres de caractères Base64.
Exemple : quelle taille pour un fichier de 1,000 octets ?
4 × ceil(1000 / 3). ceil(333.333…) = 334, et 4 × 334 = 1336. Donc 1,000 octets deviennent 1,336 caractères Base64. Stockés en UTF-8/ASCII, chaque caractère fait en général 1 octet — ne traitez pas 1,336 comme un nombre exact d’octets en mémoire.
Base64 peut-il utiliser plus de mémoire que la taille du fichier ne le suggère ?
Certains environnements stockent les chaînes avec plus de 1 octet par caractère, et encoder/décoder peut garder un tampon et une chaîne ensemble. L’usage mémoire n’est pas exactement la longueur en caractères.
Un guide simple de décision selon la taille
Si le système accepte le binaire brut, préférez-le pour la taille. Si seul le texte est autorisé, Base64 peut convenir. Pour une grosse charge, cherchez un chemin d’envoi binaire. Pour du texte sûr pour URL, envisagez Base64URL — l’expansion 3 vers 4 demeure.
- Besoin d’envoyer des données binaires
- Binaire brut autorisé ? Préférer le binaire pour la taille
- Champ texte seul ? Base64 peut convenir
- Grosse charge ? Chercher un chemin d’envoi binaire
- Besoin de texte sûr pour URL ? Envisager Base64URL
- Attendre environ 33% de texte en plus sur les grandes entrées
Base64 n’est pas conçu pour rendre les données plus petites. Il rend le binaire plus facile à représenter dans des systèmes textuels, et le coût est une taille en plus.
Encoder ou décoder Base64 dans votre navigateur
NEXNARA Encoder et décoder en Base64 encode et décode du texte, et peut transformer un fichier en Base64 ou Data URL et ramener du Base64 vers un fichier.
Le texte utilise des octets UTF-8, puis Base64 — pas seulement ASCII. Choisissez Standard ou Base64URL. La sortie fichier peut être du Base64 brut ou une Data URL (alphabet standard). Une entrée invalide est rejetée. Les octets non UTF-8 doivent aller vers un fichier, pas vers un décodage texte.
Les fichiers de plus de 10 MB peuvent ralentir l’onglet (avertissement). Les fichiers de plus de 32 MB sont bloqués.
L’encodage et le décodage se font dans votre navigateur. Le fichier n’est pas envoyé à un serveur NEXNARA pour cet outil. Les publicités et d’autres fonctions du site utilisent encore le réseau.
Collez du texte ou un fichier dans Encoder et décoder en Base64 et comparez les octets d’origine à la longueur encodée.
FAQ
Pourquoi Base64 augmente-t-il la taille du fichier ?
Il mappe 3 octets (24 bits) vers 4 caractères (4 × 6 bits). Stocké en texte, c’est environ un tiers de plus pour les grandes entrées.
Base64 est-il toujours 33% plus grand ?
Non. Les grandes entrées s’approchent d’environ 33.3%. Les toutes petites peuvent croître davantage à cause du remplissage. Utilisez 4 × ceil(n / 3).
De combien Base64 est-il plus grand que le binaire ?
La longueur standard avec remplissage est 4 × ceil(n / 3) caractères. Un préfixe Data URL en ajoute encore.
La compression Base64 réduit-elle la taille du fichier ?
Base64 ne compresse pas. gzip ou Brotli sur le texte encodé peuvent en réduire une partie ; ils n’effacent pas le surcoût dans tous les cas.
Base64URL utilise-t-il moins d’espace ?
Il peut omettre le remplissage =, donc la chaîne peut être plus courte de 0–2 caractères. La structure d’encodage 3 vers 4 est la même.
Dois-je utiliser Base64 pour les gros fichiers ?
Seulement si vous avez besoin de texte. Pour des transferts gros ou fréquents, un chemin binaire est souvent plus petit. Base64 n’est pas toujours un mauvais choix pour les API.