Pourquoi la limite de caractères de Mastodon est de 500 sur un serveur et de 11 000 sur un autre

Quelle est la limite de caractères de Mastodon ?

Mastodon en amont fixe la limite de caractères de Mastodon à 500 clusters de graphèmes, et n'importe quel opérateur de serveur peut changer ce nombre sur son propre serveur. Le chiffre vit dans une seule constante Ruby, app/validators/status_length_validator.rb :

class StatusLengthValidator < ActiveModel::Validator
  MAX_CHARS = 500
  URL_PLACEHOLDER_CHARS = 23
  URL_PLACEHOLDER = 'x' * 23

Il n'existe dans Mastodon en amont aucun réglage d'administration, aucune variable d'environnement et aucun formulaire web qui déplace MAX_CHARS. Un serveur qui applique une limite plus longue fait tourner du code patché. C'est pourquoi « la limite de caractères de Mastodon » est une question sur le serveur depuis lequel vous publiez plutôt qu'une question sur Mastodon.

Quand vous dépassez, le validateur ajoute l'erreur de la clé de traduction statuses.over_character_limit, qui en anglais se lit « character limit of %{max} exceeded ». Le %{max} est interpolé depuis la valeur que contient MAX_CHARS sur ce serveur, le message d'erreur vous donne donc lui-même le nombre local.

Qu'est-ce qui change la valeur par défaut de 500 caractères ?

Trois choses, par ordre décroissant de fréquence.

Un fork la change. Le fork glitch-soc, qu'utilisent beaucoup de serveurs de longue date, remplace la constante codée en dur par une variable d'environnement :

MAX_CHARS = (ENV['MAX_TOOT_CHARS'] || 500).to_i

Un opérateur met MAX_TOOT_CHARS=11000 dans son fichier d'environnement et tout le serveur publie à 11 000. Mastodon en amont n'a jamais adopté cette variable, ce même bouton n'existe donc pas sur une installation non modifiée.

Un patch la change. Les opérateurs qui font tourner Mastodon d'origine modifient la constante directement et reconstruisent. C'est la méthode la plus ancienne et elle survit parce que le changement tient en une ligne.

Un changement de version ne la change pas. Mastodon livre 500 comme valeur par défaut en amont depuis les premières versions du projet, et ce nombre n'a pas bougé sur toute la série 4.x.

La raison pour laquelle il n'y a pas d'interrupteur d'administration mérite d'être comprise, car elle explique pourquoi la situation ne sera pas rangée. Un serveur Mastodon ne possède pas les publications qu'il affiche. Il en reçoit la plupart d'autres serveurs, et il n'a aucun mécanisme pour en refuser une parce qu'elle est trop longue. Le développeur principal de Mastodon a rejeté des correctifs rendant la limite configurable, en faisant valoir que l'interface est conçue autour d'un seul nombre et que le niveau de base des fonctionnalités doit être le même sur chaque serveur. Garder ce nombre dans le code source fait de son relèvement un acte délibéré de quelqu'un qui modifie et redéploie.

À quel point les vrais serveurs Mastodon diffèrent-ils ?

Beaucoup. Ces chiffres viennent du point de terminaison /api/v2/instance de chaque serveur, le 12 septembre 2026.

Le suffixe +glitch sur infosec.exchange est l'indice. Ce serveur fait tourner le fork, MAX_TOOT_CHARS s'applique donc, et sa limite vaut 22 fois celle du serveur phare. Deux serveurs sur la même version 4.7.1 annoncent respectivement 500 et 1 000, ce qui est la preuve la plus nette que le numéro de version ne vous dit rien sur la limite.

Une colonne ne bouge pas. characters_reserved_per_url vaut 23 partout, parce que URL_PLACEHOLDER_CHARS se trouve dans le même fichier que MAX_CHARS et que personne ne prend la peine de le patcher. max_media_attachments non plus, fixé par Status::MEDIA_ATTACHMENTS_LIMIT = 4 dans le modèle de statut.

Qu'est-ce qui compte comme caractère sur Mastodon ?

Le validateur compte des clusters de graphèmes, ni des octets ni des points de code :

def countable_length(str)
  str.each_grapheme_cluster.size
end

Un cluster de graphèmes, c'est ce qu'un lecteur voit comme un seul caractère. L'emoji famille de quatre personnes fait sept points de code et 25 octets UTF-8, et Mastodon vous en facture 1. C'est l'inverse de la façon dont Threads compte les emojis dans sa propre limite de 500, où Meta facture chaque emoji à sa longueur en octets UTF-8 et où ce même emoji famille coûte 25. Deux plateformes, le même nombre affiché, 24 caractères d'écart sur un emoji.

Avant de compter, le validateur réécrit deux types d'entité.

Chaque URL est remplacée par URL_PLACEHOLDER, qui est littéralement 23 caractères x. Un lien de trois caractères et une URL de suivi de 400 caractères coûtent tous les deux 23. Raccourcir un lien avant de publier ne vous rapporte rien sur Mastodon.

Chaque mention est réduite à sa partie locale. La réécriture est "@#{entity[:screen_name].split('@').first}", donc @someone@long.server.example.org est compté comme @someone, huit caractères au lieu de 32. Répondre dans un fil avec six participants distants coûte bien moins que ne le laisse penser le texte visible.

L'avertissement de contenu n'est pas gratuit. combined_text colle le champ spoiler au corps réécrit avant le comptage :

def combined_text(status)
  [status.spoiler_text, countable_text(status.text)].join
end

Un avertissement de contenu de 60 caractères laisse 440 caractères pour la publication sur un serveur standard. Rien dans l'éditeur ne le dit.

Une dernière règle décide qui est vérifié. Le validateur s'ouvre sur return unless status.local? && !status.reblog?, il ne tourne donc que sur les publications créées sur ce serveur. Une publication de 9 000 caractères fédérée depuis un serveur glitch-soc est stockée et affichée en entier sur un serveur à 500 caractères, parce que la règle de longueur s'applique à l'écriture et jamais à la réception. Cette asymétrie tient à la façon dont le fédivers fait circuler les publications entre serveurs plutôt qu'à un bug de l'un d'eux.

Comment lire la limite d'un serveur avant de publier ?

Demandez au serveur. Le sérialiseur d'instance de Mastodon publie les constantes actives, aucune supposition n'est nécessaire :

"statuses": {
  "max_characters": 500,
  "max_media_attachments": 4,
  "characters_reserved_per_url": 23
}

Ce bloc vient de GET /api/v2/instance sous configuration, et le sérialiseur le construit directement à partir de StatusLengthValidator::MAX_CHARS, Status::MEDIA_ATTACHMENTS_LIMIT et StatusLengthValidator::URL_PLACEHOLDER_CHARS. Quoi qu'un opérateur ait patché, ce point de terminaison l'annonce.

Tout outil qui publie sur plus d'un serveur devrait lire cela à la connexion et le mettre en cache par serveur, puis compter des graphèmes plutôt qu'une longueur de chaîne, substituer 23 à chaque URL et ajouter le champ avertissement de contenu au total. Un compteur qui fait text.length en JavaScript se trompe sur trois points distincts, puisqu'il coupe les emojis en paires de substitution, facture les URL au prix fort et ignore le champ spoiler.

Les erreurs ne poussent pas toutes dans le même sens, et c'est ce qui les rend difficiles à remarquer. Le comptage en graphèmes et le prix de 23 caractères par URL jouent en votre faveur, un compteur naïf qui annonce 490 peut donc être une publication que le serveur accepte à 430. L'avertissement de contenu joue contre vous, ce même compteur naïf annonçant 490 sur le corps d'une publication portant un avertissement de 60 caractères est donc une publication que le serveur refuse à 550. Récupérer max_characters une fois par serveur et compter comme compte le validateur supprime toute cette classe de problèmes, et /api/v2/instance ne demande aucun jeton d'accès, il n'y a donc rien à préparer avant de pouvoir demander.

C'est la même classe de problème que les décalages en octets que Bluesky exige dans les facettes d'une publication, où le texte que vous voyez et le texte que le protocole mesure ne sont pas indexés de la même façon. Si vous comparez les deux réseaux, les règles de longueur sont l'une des différences les plus nettes dans la comparaison entre Mastodon et Bluesky.

Questions fréquentes

La limite de caractères de Mastodon est-elle de 500 ou de 5 000 ?

Mastodon en amont livre 500. Les serveurs qui font tourner le fork glitch-soc fixent leur propre valeur via la variable d'environnement MAX_TOOT_CHARS, et des valeurs de 1 000, 5 000 et 11 000 sont toutes en production aujourd'hui. Vérifiez /api/v2/instance pour le serveur depuis lequel vous publiez.

Un administrateur peut-il changer la limite de caractères depuis le tableau de bord Mastodon ?

Non. Il n'y a aucun réglage dans l'interface d'administration. En amont, il faut modifier MAX_CHARS dans app/validators/status_length_validator.rb et reconstruire ; glitch-soc lit la variable d'environnement MAX_TOOT_CHARS au démarrage.

Combien de caractères coûte un lien sur Mastodon ?

Exactement 23, fixés par URL_PLACEHOLDER_CHARS. Le validateur remplace chaque URL extraite par un espace réservé de 23 caractères avant de compter, la longueur du lien n'a donc aucun effet sur votre budget restant.

L'avertissement de contenu compte-t-il dans la limite ?

Oui. La méthode combined_text colle le texte du spoiler au corps de la publication avant que le comptage ne s'exécute, un long avertissement de contenu mange donc directement les caractères disponibles pour la publication.

Les emojis comptent-ils pour un caractère sur Mastodon ?

Oui. Le comptage porte sur les clusters de graphèmes, un emoji avec teinte de peau ou un emoji famille à plusieurs personnes coûte donc 1, quel que soit le nombre de points de code ou d'octets qu'il contient.

Que se passe-t-il si une longue publication fédère vers un serveur à 500 caractères ?

Elle arrive et s'affiche en entier. Le validateur de longueur ne tourne que sur les publications écrites localement, un serveur avec une limite de 500 caractères stocke et affiche donc quand même une publication de 11 000 caractères reçue d'ailleurs.

Pourquoi un compteur de caractères en JavaScript donne-t-il un résultat faux pour les publications Mastodon ?

Un compteur qui utilise text.length en JavaScript découpe un emoji multi-personnages en ses paires de substitution séparées, facture la longueur complète de chaque URL au lieu des 23 caractères fixes utilisés par Mastodon, et ignore complètement le champ de l'avertissement de contenu. Mastodon compte des clusters de graphèmes, remplace chaque URL par un espace réservé de 23 caractères et ajoute le texte de l'avertissement de contenu avant de vérifier la limite. Les deux méthodes de comptage peuvent diverger dans les deux sens, si bien qu'un compteur naïf affichant 490 peut appartenir à une publication acceptée à 430 ou refusée à 550 selon son contenu.

Mentionner quelqu'un sur un serveur distant coûte-t-il vraiment moins cher qu'il n'y paraît ?

Mastodon réduit chaque mention à sa partie locale avant de compter, si bien que @someone@long.server.example.org coûte huit caractères au lieu des 32 visibles dans l'éditeur. Une réponse dans un fil avec plusieurs participants distants peut sembler longue dans l'éditeur, mais coûte bien moins cher contre la limite que ne le suggère le texte affiché.

Jusqu'où monte la limite de caractères sur de vrais serveurs Mastodon ?

todon.eu affiche 13 120 caractères via son point de terminaison /api/v2/instance et infosec.exchange en affiche 11 000, contre 500 sur mastodon.social. Tous deux atteignent ces chiffres en faisant tourner un fork avec la limite définie dans l'environnement, et non grâce à une option offerte par Mastodon non modifié.

Pourquoi Mastodon ne propose-t-il pas de menu déroulant par serveur pour la limite de caractères ?

Le développeur principal de Mastodon a refusé des correctifs rendant la limite configurable, au motif que l'interface est conçue autour d'un seul nombre et que le niveau de base des fonctionnalités doit être le même sur chaque serveur. La fédération aggrave le problème, puisque le validateur de longueur ne s'exécute que sur les publications rédigées localement et que tous les autres serveurs stockent et affichent ce qui leur arrive. Les opérateurs qui veulent une limite plus longue modifient eux-mêmes la constante ou font tourner un fork comme glitch-soc.