Por que o limite de caracteres do Mastodon é 500 em um servidor e 11.000 em outro

O que é o limite de caracteres do Mastodon?

O Mastodon upstream define o limite de caracteres do Mastodon em 500 clusters de grafemas, e qualquer operador de servidor pode mudar esse número no próprio servidor. O valor vive em uma única constante Ruby, app/validators/status_length_validator.rb:

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

Não existe no Mastodon upstream nenhuma opção de administração, nenhuma variável de ambiente e nenhum formulário web que mexa em MAX_CHARS. Um servidor que roda com um limite maior roda código modificado. Por isso "o limite de caracteres do Mastodon" é uma pergunta sobre de qual servidor você publica, e não uma pergunta sobre o Mastodon.

Quando você passa do limite, o validador adiciona o erro da chave de tradução statuses.over_character_limit, que em inglês diz "character limit of %{max} exceeded". O %{max} é interpolado a partir do que MAX_CHARS guarda naquele servidor, então a própria mensagem de erro informa o número local.

O que muda o padrão de 500 caracteres?

Três coisas, em ordem decrescente de frequência.

Um fork muda. O fork glitch-soc, usado por muitos servidores antigos, troca a constante fixa por uma variável de ambiente:

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

Um operador define MAX_TOOT_CHARS=11000 no arquivo de ambiente e o servidor inteiro publica com 11.000. O Mastodon upstream nunca adotou essa variável, então o mesmo controle não existe em uma instalação sem modificações.

Um patch muda. Operadores que rodam o Mastodon original editam a constante direto e recompilam. É o método mais antigo e sobrevive porque a mudança tem uma linha.

Uma troca de versão não muda. O Mastodon entrega 500 como padrão upstream desde as primeiras versões do projeto, e o número não se moveu em nenhuma da série 4.x.

Vale entender por que não existe um botão de administração, porque isso explica por que a situação não vai ser arrumada. Um servidor Mastodon não é dono das publicações que exibe. Ele recebe a maioria de outros servidores e não tem mecanismo para recusar uma por ser longa demais. O desenvolvedor principal do Mastodon já rejeitou patches que tornariam o limite configurável, argumentando que a interface é desenhada em torno de um número só e que o nível básico de funcionalidade deveria ser o mesmo em todo servidor. Manter o número no código-fonte transforma elevá-lo em um ato deliberado de alguém que edita e sobe de novo.

Quão diferentes são os servidores reais do Mastodon?

Muito. Estes números vieram do endpoint /api/v2/instance de cada servidor em 12 de setembro de 2026.

O sufixo +glitch em infosec.exchange é a pista. Ele roda o fork, então MAX_TOOT_CHARS se aplica, e o limite dele é 22 vezes o do servidor principal. Dois servidores na mesma versão 4.7.1 informam 500 e 1.000, que é a evidência mais clara de que o número da versão não diz nada sobre o limite.

Uma coluna não se mexe. characters_reserved_per_url é 23 em todo lugar, porque URL_PLACEHOLDER_CHARS fica no mesmo arquivo que MAX_CHARS e ninguém se dá ao trabalho de alterar. max_media_attachments também não, fixado por Status::MEDIA_ATTACHMENTS_LIMIT = 4 no modelo de status.

O que conta como caractere no Mastodon?

O validador conta clusters de grafemas, não bytes nem pontos de código:

def countable_length(str)
  str.each_grapheme_cluster.size
end

Um cluster de grafemas é o que o leitor enxerga como um caractere. O emoji de família de quatro pessoas tem sete pontos de código e 25 bytes UTF-8, e o Mastodon cobra 1 por ele. É o oposto de como o Threads conta emojis no próprio limite de 500, onde a Meta cobra cada emoji pelo tamanho em bytes UTF-8 e esse mesmo emoji de família custa 25. Duas plataformas, o mesmo número de manchete, 24 caracteres de diferença em um emoji.

Antes de contar, o validador reescreve dois tipos de entidade.

Toda URL é substituída por URL_PLACEHOLDER, que é literalmente 23 caracteres x. Um link de três caracteres e uma URL de rastreamento de 400 caracteres custam 23 os dois. Encurtar um link antes de publicar não rende nada no Mastodon.

Toda menção é cortada para a parte local. A reescrita é "@#{entity[:screen_name].split('@').first}", então @someone@long.server.example.org conta como @someone, oito caracteres em vez de 32. Responder em uma conversa com seis participantes remotos custa bem menos do que o texto visível sugere.

O aviso de conteúdo não é de graça. combined_text junta o campo de spoiler ao corpo reescrito antes da contagem:

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

Um aviso de conteúdo de 60 caracteres deixa 440 caracteres para a publicação em um servidor padrão. Nada no editor avisa isso.

Mais uma regra decide quem é verificado. O validador abre com return unless status.local? && !status.reblog?, então só roda em publicações criadas naquele servidor. Uma publicação de 9.000 caracteres federada de um servidor glitch-soc é armazenada e exibida inteira em um servidor de 500 caracteres, porque a regra de tamanho vale na hora de escrever e nunca no recebimento. Essa assimetria é própria de como o fediverso passa publicações entre servidores, e não um defeito de um servidor específico.

Como ler o limite de um servidor antes de publicar?

Pergunte ao servidor. O serializador de instância do Mastodon publica as constantes em uso, então não é preciso adivinhar:

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

Esse bloco vem de GET /api/v2/instance em configuration, e o serializador o monta direto de StatusLengthValidator::MAX_CHARS, Status::MEDIA_ATTACHMENTS_LIMIT e StatusLengthValidator::URL_PLACEHOLDER_CHARS. O que o operador tiver modificado, este endpoint informa.

Qualquer ferramenta que publique em mais de um servidor deve ler isso na conexão e guardar em cache por servidor, depois contar grafemas em vez do tamanho da string, trocar cada URL por 23 e somar o campo do aviso de conteúdo ao total. Um contador que faz text.length em JavaScript erra por três motivos separados, já que quebra emojis em pares substitutos, cobra o preço cheio pelas URLs e ignora o campo de spoiler.

Os erros não puxam todos para o mesmo lado, e é isso que os torna difíceis de perceber. A contagem por grafemas e o preço de 23 caracteres por URL jogam a seu favor, então um contador ingênuo que mostra 490 pode ser uma publicação que o servidor aceita com 430. O aviso de conteúdo joga contra você, então esse mesmo contador ingênuo mostrando 490 no corpo de uma publicação com um aviso de 60 caracteres é uma publicação que o servidor recusa com 550. Buscar max_characters uma vez por servidor e contar do jeito que o validador conta elimina a classe inteira de problema, e /api/v2/instance não precisa de token de acesso, então não há nada a preparar antes de perguntar.

Essa é a mesma classe de problema dos deslocamentos em bytes que o Bluesky exige nas facetas de uma publicação, em que o texto que você vê e o texto que o protocolo mede são indexados de formas diferentes. Se você está pesando as duas redes, as regras de tamanho são uma das diferenças mais nítidas em como Mastodon e Bluesky se comparam.

Perguntas frequentes

O limite de caracteres do Mastodon é 500 ou 5.000?

O Mastodon upstream entrega 500. Servidores que rodam o fork glitch-soc definem o próprio valor pela variável de ambiente MAX_TOOT_CHARS, e valores de 1.000, 5.000 e 11.000 estão todos em produção hoje. Verifique /api/v2/instance do servidor de onde você publica.

Um administrador pode mudar o limite de caracteres pelo painel do Mastodon?

Não. Não existe essa opção na interface de administração. O upstream exige editar MAX_CHARS em app/validators/status_length_validator.rb e recompilar; o glitch-soc lê a variável de ambiente MAX_TOOT_CHARS na inicialização.

Quantos caracteres custa um link no Mastodon?

Exatamente 23, definidos por URL_PLACEHOLDER_CHARS. O validador troca cada URL extraída por um marcador de 23 caracteres antes de contar, então o tamanho do link não muda o seu orçamento restante.

O aviso de conteúdo conta para o limite?

Sim. O método combined_text junta o texto de spoiler ao corpo da publicação antes de a contagem rodar, então um aviso de conteúdo longo consome direto os caracteres disponíveis para a publicação.

Emojis contam como um caractere no Mastodon?

Sim. A contagem é feita sobre clusters de grafemas, então um emoji com tom de pele ou um emoji de família com várias pessoas custa 1, não importa quantos pontos de código ou bytes ele contenha.

O que acontece quando uma publicação longa federa para um servidor de 500 caracteres?

Ela chega e aparece inteira. O validador de tamanho roda só em publicações escritas localmente, então um servidor com limite de 500 caracteres ainda armazena e renderiza uma publicação de 11.000 caracteres recebida de outro lugar.

Por que um contador de caracteres em JavaScript dá um resultado errado para publicações do Mastodon?

Um contador que usa text.length em JavaScript divide um emoji com várias pessoas em seus pares substitutos separados, cobra o comprimento total de cada URL em vez dos 23 caracteres fixos que o Mastodon usa, e ignora completamente o campo de aviso de conteúdo. O Mastodon conta clusters de grafemas, substitui cada URL por um marcador de 23 caracteres e soma o texto do aviso de conteúdo antes de checar o limite. As duas formas de contagem podem divergir nos dois sentidos, então um contador ingênuo mostrando 490 pode pertencer a uma publicação aceita em 430 ou rejeitada em 550, dependendo do que ela contém.

Quanto mais barato é mencionar alguém em um servidor remoto do que parece?

O Mastodon reduz cada menção à sua parte local antes de contar, então @someone@long.server.example.org custa oito caracteres em vez dos 32 visíveis no editor. Uma resposta em uma conversa com vários participantes remotos pode parecer longa no editor, mas custa bem menos contra o limite do que o texto exibido sugere.

Até onde vai o limite de caracteres em servidores reais do Mastodon?

O todon.eu reporta 13.120 caracteres pelo seu endpoint /api/v2/instance e o infosec.exchange reporta 11.000, contra 500 no mastodon.social. Os dois chegam a esses números rodando um fork com o limite definido no ambiente, não por uma opção oferecida pelo Mastodon original.

Por que o Mastodon não oferece um menu suspenso por servidor para o limite de caracteres?

O desenvolvedor principal do Mastodon já recusou patches que tornariam o limite configurável, sob o argumento de que a interface é desenhada em torno de um número só e que o nível básico de funcionalidade deveria ser o mesmo em todo servidor. A federação agrava isso, já que o validador de tamanho roda só em publicações escritas localmente e todos os outros servidores armazenam e exibem o que chega. Operadores que querem um limite maior editam a constante por conta própria ou rodam um fork como o glitch-soc.