TL;DR, Réponse Rapide
8 min de lectureBluesky plafonne une image de post à 2,000,000 octets, un nombre écrit comme maxSize dans le lexicon app.bsky.embed.images, le schéma du protocole. Cela fait deux millions d'octets, pas 2 MiB, donc une image que votre gestionnaire de fichiers appelle 1.95 MB dépasse déjà. Les avatars, les bannières et les vignettes de cartes de lien sont tenus à la moitié, 1,000,000 octets. L'application Bluesky n'envoie jamais votre fichier d'origine : elle réencode chaque image de post en JPEG à 4,000 pixels au plus et cherche un réglage de qualité qui passe sous le plafond.
Quelle est la limite de taille d'image de Bluesky ?
Chaque image jointe à un post Bluesky est plafonnée à 2 000 000 octets, donc la limite de taille d'image de Bluesky vaut deux millions d'octets et non les 2 MiB que la plupart des gestionnaires de fichiers désignent quand ils affichent « 2 MB ». Ce nombre n'est pas enfoui dans un article d'aide. Il siège dans le schéma du protocole, dans app.bsky.embed.images, sous la forme d'un champ nommé maxSize sur le blob de l'image :
"image": {
"type": "blob",
"description": "The raw image file. May be up to 2 MB, formerly limited to 1 MB.",
"accept": ["image/*"],
"maxSize": 2000000
}Deux millions d'octets font 1,907 MiB. Un JPEG exporté que le Finder de macOS annonce à « 1.9 MB » pèse environ 1 992 294 octets et passe de justesse ; un autre annoncé à « 2 MB » pèse 2 097 152 octets et ne passe pas. C'est dans cet écart de 97 152 octets que vit l'essentiel de la confusion sur cette limite.
La formulation du lexicon conserve l'historique. Elle dit que le blob « May be up to 2 MB, formerly limited to 1 MB », ce qui explique pourquoi tant de guides de tailles tiers publient encore 1 MB. Ils avaient raison il y a deux ans et personne n'est revenu les corriger.
Quel envoi Bluesky reçoit quelle limite ?
Bluesky n'a pas une limite d'image unique. Il a six plafonds de blob déclarés dans six lexicons, et ils se contredisent volontairement.
| Lexicon | Ce qu'il contient | maxSize | accept |
|---|---|---|---|
app.bsky.embed.images | Images de post, jusqu'à 4 | 2000000 | image/* |
app.bsky.embed.gallery | Éléments de galerie | 2000000 | image/* |
app.bsky.embed.external | Vignette de carte de lien | 1000000 | image/* |
app.bsky.actor.profile | Avatar | 1000000 | image/png, image/jpeg |
app.bsky.actor.profile | Bannière | 1000000 | image/png, image/jpeg |
app.bsky.embed.video | Fichier vidéo | 300000000 | video/mp4 |
Deux points de ce tableau piègent les gens. Les avatars et les bannières sont plafonnés à la moitié d'une image de post, et ils refusent tout ce qui n'est pas PNG ou JPEG, donc un avatar WebP qui s'envoie très bien en image de post est rejeté sur votre profil. Et le blob vidéo monte à 300 000 000 octets, sa propre description notant qu'il était « formerly limited to 100mb », exactement le même schéma que le plafond des images.
Le lexicon plus récent app.bsky.embed.gallery autorise un maxLength de 20 éléments, mais son propre commentaire de schéma demande aux clients de se retenir : « The schema-level maxLength of 20 is a future-proof ceiling. Clients should currently enforce a soft limit of 10 items in authoring UIs. » L'embed plus ancien app.bsky.embed.images reste à 4.

Que fait l'application Bluesky à votre image avant l'envoi ?
Le client officiel n'envoie jamais votre fichier d'origine. Avant d'appeler uploadBlob, le composeur exécute compressImage contre une configuration dans src/lib/constants.ts :
export const IMAGE_SIZE_CONFIG_POSTS = {
maxDimension: 4000,
maxSize: 2000000,
};Cette fonction ne vérifie pas si votre fichier est déjà assez petit. Elle réencode sans condition, toujours en JPEG, et fait une recherche binaire du niveau de qualité qui atterrit sous 2 000 000 octets. Elle démarre à la qualité 51, monte si le résultat tient et descend sinon, puis s'arrête dès que la fenêtre de recherche se referme.
Quand une image résiste à la compression, le code refuse de continuer à baisser la qualité. Le commentaire dans la source énonce la règle : « binary search will check 51, 26, 13(rounded). We don't want to go below 25, so if we've halved to 13, reset the loop and reduce the image dimensions instead. » Chaque réinitialisation multiplie la dimension de travail par 0,8, ce qui fait descendre 4000 à 3200, puis 2560, puis 2048, puis environ 1638 pixels. Quatre réinitialisations sont le plafond, et au-delà l'envoi échoue avec Unable to compress image.
Trois conséquences découlent du fait que chaque image de post est réencodée en JPEG. La transparence disparaît, car le JPEG n'a pas de canal alpha, donc un logo PNG sur fond transparent arrive avec un fond plein. Le texte net et les aplats de couleur attrapent des artefacts de rebond que le même fichier ne montrerait pas sur une plateforme qui laisse passer le PNG. Et vos réglages d'export soignés partent à la poubelle, puisque le client choisit son propre nombre de qualité sans tenir compte du vôtre. Le même réencodage remplit aussi le champ aspectRatio à partir de la sortie compressée et non de votre original, et ce champ vaut deux entiers avec un minimum de 1, pas un flottant.
Pourquoi une image trop lourde passe-t-elle parfois quand même ?
Parce que l'envoi du blob et l'écriture de l'enregistrement sont deux requêtes différentes avec deux limites différentes, et seule la seconde lit le lexicon.
Le point d'entrée com.atproto.repo.uploadBlob applique le plafond propre au serveur, qui vaut par défaut 5 * 1024 * 1024 dans le PDS de référence, soit 5 242 880 octets, configurable via la variable d'environnement PDS_BLOB_UPLOAD_LIMIT. Dépassez-le et le flux s'interrompt avec Max size of 5242880 bytes exceeded. Restez dessous et le blob est accepté même à 4 MB, bien au-delà des 2 000 000 du lexicon.
Le lexicon dit lui-même où se produit la vraie vérification. Sa description indique : « The blob will be deleted if it is not referenced within a time window (eg, minutes). Blob restrictions (mimetype, size, etc) are enforced when the reference is created. » Une image de 4 MB s'envoie donc avec succès, reste en stockage temporaire, échoue à la validation quand vous tentez de la joindre à un post, et part au ramasse-miettes quelques minutes plus tard. Qui publie via un client maison plutôt que l'application officielle se heurte à cet ordre et lit l'envoi réussi comme un feu vert.
Ce même point d'entrée porte une limite de 1 000 points par jour, ce qui plafonne durement le nombre d'images qu'un compte peut pousser en 24 heures. C'est un plafond parmi d'autres qu'il vaut la peine de lire avec les limites de débit que l'AT Protocol applique aux écritures si vous publiez selon un calendrier.
AdaptlyPost
Essai gratuit de 7 jours
Analyses multiplateforme
Boîte sociale
Assistant IA

Quelles dimensions exporter pour Bluesky ?
Rien dans le lexicon ne contraint les dimensions en pixels. Aucune largeur minimale, aucune hauteur maximale, aucun rapport d'aspect imposé nulle part dans app.bsky.embed.images. Le seul nombre de dimension qui existe est le maxDimension: 4000 du client, et c'est un déclencheur de redimensionnement, pas un refus.
Le conseil pratique qui en découle est court. Exportez à 2 000 pixels sur le grand côté ou moins, pour que le client n'ait aucune raison de redimensionner ni de casser la qualité. Utilisez le JPEG vous-même, puisque l'application convertira en JPEG de toute façon et que votre encodeur est mieux réglé qu'une recherche binaire de qualité. Gardez le fichier sous environ 1,8 MB pour laisser de la marge au réencodage. Si vous avez besoin de transparence ou de texte net, aplatissez l'image sur la couleur de fond voulue avant l'envoi, car l'autre option est de laisser l'encodeur JPEG choisir à votre place.
Le texte alternatif n'a aucun plafond déclaré dans le lexicon. L'application officielle applique son propre MAX_ALT_TEXT = 2000, une règle de client et non de protocole, donc les autres clients fixent la leur. Cela reflète la façon dont Bluesky traite les liens et les mentions, où les décalages en octets dans les facets d'un post relèvent du protocole et le rendu relève du client.
Si vous comparez les spécifications entre réseaux avant de construire un préréglage d'export, le calcul sur les dimensions d'image d'Instagram fonctionne autrement, puisque Meta redimensionne côté serveur au lieu de le faire faire au client. Et si vous mettez des images en file à l'avance, l'étape de compression fait partie de la programmation de posts sur Bluesky, que vous l'exécutiez vous-même ou qu'un client s'en charge.
Questions fréquentes
La limite d'image de Bluesky est-elle de 1 MB ou de 2 MB ?
Elle est de 2 000 000 octets. Le chiffre de 1 MB était juste avant le relèvement du plafond, et le lexicon garde encore trace du changement dans sa propre description : « May be up to 2 MB, formerly limited to 1 MB. » Les guides qui publient 1 MB n'ont pas été mis à jour depuis.
Combien d'images un post Bluesky peut-il contenir ?
Quatre, fixées par "maxLength": 4 sur le tableau images dans app.bsky.embed.images. Le lexicon plus récent app.bsky.embed.gallery porte le plafond de schéma à 20 tout en demandant aux clients d'appliquer une limite souple de 10.
Bluesky accepte-t-il le PNG et le WebP ?
Le blob d'image de post déclare "accept": ["image/*"], donc tout type MIME d'image passe la validation du protocole. L'application officielle convertit tout en JPEG avant l'envoi, donc un PNG que vous envoyez arrive en JPEG. Les avatars et les bannières sont plus stricts et n'acceptent que image/png et image/jpeg.
Quelle est la limite de taille des avatars et bannières sur Bluesky ?
Les deux valent 1000000 octets dans app.bsky.actor.profile, la moitié du plafond d'une image de post. Les avatars de générateurs de flux et de listes dans app.bsky.feed.generator et app.bsky.graph.list utilisent le même chiffre de 1 000 000.
Pourquoi mon image s'est-elle envoyée alors que mon post a échoué ?
Le point d'entrée d'envoi vérifie la limite de blob du serveur, qui vaut par défaut 5 242 880 octets, et le plafond de 2 000 000 du lexicon est vérifié plus tard, quand un enregistrement référence le blob. Une image comprise entre ces deux nombres s'envoie puis échoue au moment de publier.
Bluesky compresse-t-il les images après l'envoi ?
L'application compresse avant l'envoi, pas après. L'App View sert ensuite des dérivés redimensionnés depuis son CDN pour les vignettes et les vues en taille réelle, et le lexicon note que le fichier servi « May or may not be the exact original blob ». Le blob stocké dans votre dépôt est exactement ce que le client a envoyé.
Bluesky compresse-t-il une image déjà sous 2 000 000 d'octets ?
Le composeur de Bluesky lance compressImage sur chaque image de post quelle que soit sa taille de départ, et la recompresse en JPEG avant même de chercher la qualité. La fonction ne vérifie jamais la taille du fichier au départ, donc même un export déjà bien calibré reçoit une qualité JPEG choisie par l'app.
Pourquoi mon PNG transparent perd-il son fond sur Bluesky ?
Le JPEG n'a pas de canal alpha, et l'application Bluesky convertit chaque image de post en JPEG avant l'envoi, donc le fond transparent d'un PNG se retrouve rempli d'une couleur unie. Cela arrive même si votre fichier d'origine était correct, parce que compressImage recompresse toutes les images sans exception.
Bluesky garde-t-il le rapport d'aspect de mon fichier d'origine ?
L'app remplit le champ aspectRatio à partir du JPEG déjà compressé, pas de votre fichier d'origine, car ce rapport est calculé après le redimensionnement et la recherche de qualité. Ce champ stocke deux entiers avec un minimum de 1, pas un ratio décimal.
Y a-t-il une limite de caractères pour le texte alternatif sur Bluesky ?
Le lexique app.bsky.embed.images ne fixe aucun plafond pour le texte alternatif. L'application officielle Bluesky applique sa propre règle côté client, MAX_ALT_TEXT = 2000, une décision de l'app plutôt qu'une limite du protocole, donc d'autres clients peuvent fixer la leur.
AdaptlyPost
Essai gratuit de 7 jours
Analyses multiplateforme
Boîte sociale
Assistant IA
Mettez cela en pratique avec AdaptlyPost
Cet article vous a-t-il été utile ?
Dites-nous ce que vous en pensez !
Nous voir plus souvent sur Google
Un clic définit AdaptlyPost comme source préférée. Nos articles remontent alors dans vos À la une, en mode IA et dans les aperçus IA.
Avant de partir...
AdaptlyPost
Planifiez vos contenus sur toutes les plateformes
Gérez tous vos comptes de réseaux sociaux en un seul endroit avec AdaptlyPost.
Analyses multiplateforme
Boîte sociale
Assistant IA
Termes connexes du glossaire


Les deux enregistrements derrière un handle de domaine personnalisé Bluesky
Un handle de domaine personnalisé Bluesky exige un enregistrement : TXT sur _atproto ou texte brut sur /.well-known/atproto-did. Les valeurs et les TLD exclus.


Pourquoi la limite de caractères de Threads compte les emojis en octets UTF-8
Le plafond est de 500, mais la limite de caractères de Threads mesure chaque emoji en octets UTF-8 : un emoji famille coûte 25. Comment compter juste.


Pourquoi la limite de caractères des légendes TikTok se mesure en runes UTF-16
La limite de caractères des légendes TikTok est de 2200 runes UTF-16 en vidéo et de 90 pour un titre de photo. Un seul emoji peut en coûter onze.
Articles Connexes


Comment fonctionne un générateur de feeds Bluesky, du lexicon au feed en direct
Un générateur de feeds Bluesky est un service HTTPS qui répond à une requête XRPC. Les lexicons, l'entrée du document DID, le JWT et les zones d'ombre.


Pourquoi la métrique comptes ayant interagi sur Instagram n'égale pas les interactions
La métrique comptes ayant interagi sur Instagram compte des comptes uniques, pas des actions, et les champs de l'API ne suivent plus les libellés de l'app.


Pourquoi Bluesky facets byteStart byteEnd comptent des octets, pas des caractères
Les offsets Bluesky facets byteStart byteEnd comptent des octets UTF-8, pas les index UTF-16 de JavaScript. L'avertissement du lexicon, un exemple, du code.

