Por qué el límite de caracteres de Mastodon es 500 en un servidor y 11.000 en otro

¿Qué es el límite de caracteres de Mastodon?

Mastodon upstream fija el límite de caracteres de Mastodon en 500 clústeres de grafemas, y cualquier operador de servidor puede cambiar esa cifra en su propio servidor. La cifra vive en una sola constante de Ruby, app/validators/status_length_validator.rb:

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

En Mastodon upstream no hay ajuste de administración, ni variable de entorno, ni formulario web que mueva MAX_CHARS. Un servidor que funciona con un límite más largo funciona con código parcheado. Por eso "el límite de caracteres de Mastodon" es una pregunta sobre desde qué servidor publicas y no una pregunta sobre Mastodon.

Cuando te pasas, el validador añade el error de la clave de traducción statuses.over_character_limit, que en inglés dice "character limit of %{max} exceeded". El %{max} se interpola a partir de lo que contenga MAX_CHARS en ese servidor, así que el propio mensaje de error te dice la cifra local.

¿Qué cambia el valor por defecto de 500 caracteres?

Tres cosas, en orden descendente de frecuencia.

Un fork lo cambia. El fork glitch-soc, que usan muchos servidores veteranos, sustituye la constante fija por una variable de entorno:

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

Un operador pone MAX_TOOT_CHARS=11000 en su archivo de entorno y todo el servidor publica a 11.000. Mastodon upstream nunca ha adoptado esa variable, así que el mismo control no existe en una instalación sin modificar.

Un parche lo cambia. Los operadores que ejecutan Mastodon de serie editan la constante directamente y recompilan. Es el método más antiguo y sobrevive porque el cambio es de una línea.

Un salto de versión no lo cambia. Mastodon lleva enviando 500 como valor por defecto upstream desde las primeras versiones del proyecto, y no se ha movido en ninguna de la serie 4.x.

Merece la pena entender por qué no hay un interruptor de administración, porque explica por qué la situación no se va a ordenar. Un servidor de Mastodon no es dueño de las publicaciones que muestra. Recibe la mayoría de otros servidores y no tiene ningún mecanismo para rechazar una por ser demasiado larga. El desarrollador principal de Mastodon ha rechazado parches que hacen configurable el límite, argumentando que la interfaz está diseñada en torno a una sola cifra y que el nivel básico de funcionalidad debería ser el mismo en todos los servidores. Mantener la cifra en el código fuente convierte subirla en un acto deliberado de alguien que edita y vuelve a desplegar.

¿Cuánto se diferencian los servidores reales de Mastodon?

Mucho. Estas cifras salieron del propio endpoint /api/v2/instance de cada servidor el 12 de septiembre de 2026.

El sufijo +glitch de infosec.exchange es la pista. Funciona con el fork, así que se aplica MAX_TOOT_CHARS, y su límite es 22 veces el del servidor insignia. Dos servidores con la misma versión 4.7.1 declaran 500 y 1.000 respectivamente, que es la prueba más clara de que el número de versión no te dice nada sobre el límite.

Una columna no se mueve. characters_reserved_per_url es 23 en todas partes, porque URL_PLACEHOLDER_CHARS está en el mismo archivo que MAX_CHARS y nadie se molesta en parchearlo. Tampoco se mueve max_media_attachments, fijado por Status::MEDIA_ATTACHMENTS_LIMIT = 4 en el modelo de estado.

¿Qué cuenta como carácter en Mastodon?

El validador cuenta clústeres de grafemas, ni bytes ni puntos de código:

def countable_length(str)
  str.each_grapheme_cluster.size
end

Un clúster de grafemas es lo que un lector ve como un carácter. El emoji de familia de cuatro personas son siete puntos de código y 25 bytes UTF-8, y Mastodon te cobra 1. Es lo contrario de cómo Threads cuenta los emojis contra su propio límite de 500, donde Meta cobra cada emoji por su longitud en bytes UTF-8 y ese mismo emoji de familia cuesta 25. Dos plataformas, la misma cifra de titular, 24 caracteres de diferencia en un emoji.

Antes de contar, el validador reescribe dos tipos de entidad.

Cada URL se sustituye por URL_PLACEHOLDER, que son literalmente 23 caracteres x. Un enlace de tres caracteres y una URL de seguimiento de 400 caracteres cuestan los dos 23. Acortar un enlace antes de publicar no te aporta nada en Mastodon.

Cada mención se recorta a su parte local. La reescritura es "@#{entity[:screen_name].split('@').first}", así que @someone@long.server.example.org se cuenta como @someone, ocho caracteres en lugar de 32. Responder en un hilo con seis participantes remotos cuesta mucho menos de lo que sugiere el texto visible.

El aviso de contenido no es gratis. combined_text une el campo del spoiler al cuerpo reescrito antes de contar:

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

Un aviso de contenido de 60 caracteres deja 440 caracteres para la publicación en un servidor estándar. Nada en el editor lo dice.

Una regla más decide a quién se comprueba. El validador abre con return unless status.local? && !status.reblog?, así que solo se ejecuta en publicaciones creadas en ese servidor. Una publicación de 9.000 caracteres federada desde un servidor glitch-soc se almacena y se muestra entera en un servidor de 500 caracteres, porque la regla de longitud se aplica al escribir y nunca al recibir. Esa asimetría es propia de cómo el fediverso pasa publicaciones entre servidores y no un fallo de ninguno de ellos.

¿Cómo se lee el límite de un servidor antes de publicar?

Pregúntaselo al servidor. El serializador de instancia de Mastodon publica las constantes vivas, así que no hay que adivinar nada:

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

Ese bloque viene de GET /api/v2/instance bajo configuration, y el serializador lo construye directamente a partir de StatusLengthValidator::MAX_CHARS, Status::MEDIA_ATTACHMENTS_LIMIT y StatusLengthValidator::URL_PLACEHOLDER_CHARS. Lo que sea que haya parcheado un operador, este endpoint lo declara.

Cualquier herramienta que publique en más de un servidor debería leer esto al conectar y guardarlo en caché por servidor, luego contar grafemas en lugar de longitud de cadena, sustituir 23 por cada URL y sumar el campo del aviso de contenido al total. Un contador que hace text.length en JavaScript se equivoca por tres motivos distintos, porque parte los emojis en pares suplentes, cobra el precio completo por las URL e ignora el campo del spoiler.

Los errores no empujan todos en la misma dirección, que es lo que los hace difíciles de notar. El recuento por grafemas y el precio de 23 caracteres por URL juegan a tu favor, así que un contador ingenuo que marca 490 puede ser una publicación que el servidor acepta en 430. El aviso de contenido juega en tu contra, así que ese mismo contador ingenuo marcando 490 en el cuerpo de una publicación que lleva un aviso de 60 caracteres es una publicación que el servidor rechaza en 550. Pedir max_characters una vez por servidor y contar como cuenta el validador elimina toda la clase de problema, y /api/v2/instance no necesita token de acceso, así que no hay nada que preparar antes de poder preguntar.

Es la misma clase de problema que los desplazamientos en bytes que Bluesky exige en las facetas de una publicación, donde el texto que ves y el texto que mide el protocolo se indexan de forma distinta. Si estás sopesando las dos redes, las reglas de longitud son una de las diferencias más marcadas en la comparación entre Mastodon y Bluesky.

Preguntas frecuentes

¿El límite de caracteres de Mastodon es 500 o 5.000?

Mastodon upstream envía 500. Los servidores que ejecutan el fork glitch-soc fijan su propio valor mediante la variable de entorno MAX_TOOT_CHARS, y hoy hay en producción valores de 1.000, 5.000 y 11.000. Consulta /api/v2/instance para el servidor desde el que publicas.

¿Puede un administrador cambiar el límite de caracteres desde el panel de Mastodon?

No. No hay ningún ajuste en la interfaz de administración. Upstream exige editar MAX_CHARS en app/validators/status_length_validator.rb y recompilar; glitch-soc lee la variable de entorno MAX_TOOT_CHARS al arrancar.

¿Cuántos caracteres cuesta un enlace en Mastodon?

Exactamente 23, fijados por URL_PLACEHOLDER_CHARS. El validador cambia cada URL extraída por un marcador de 23 caracteres antes de contar, así que la longitud del enlace no afecta a tu presupuesto restante.

¿El aviso de contenido cuenta para el límite?

Sí. El método combined_text une el texto del spoiler al cuerpo de la publicación antes de que se ejecute el recuento, así que un aviso de contenido largo se come directamente los caracteres disponibles para la publicación.

¿Los emojis cuentan como un carácter en Mastodon?

Sí. El recuento es sobre clústeres de grafemas, así que un emoji con tono de piel o un emoji de familia de varias personas cuesta 1 sin importar cuántos puntos de código o bytes contenga.

¿Qué pasa si una publicación larga federa a un servidor de 500 caracteres?

Llega y se muestra entera. El validador de longitud se ejecuta solo en publicaciones escritas localmente, así que un servidor con un límite de 500 caracteres sigue almacenando y mostrando una publicación de 11.000 caracteres recibida de otro sitio.

¿Por qué un contador de caracteres en JavaScript da un resultado incorrecto para las publicaciones de Mastodon?

Un contador que usa text.length en JavaScript divide un emoji de varias personas en sus pares suplentes por separado, cobra la longitud completa de cada URL en lugar de los 23 caracteres fijos que usa Mastodon, e ignora por completo el campo del aviso de contenido. Mastodon cuenta clústeres de grafemas, sustituye cada URL por un marcador de 23 caracteres y suma el texto del aviso de contenido antes de comprobar el límite. Las dos formas de contar pueden discrepar en ambos sentidos, así que un contador ingenuo que marque 490 puede pertenecer a una publicación aceptada en 430 o rechazada en 550, según lo que contenga.

¿Cuánto más barato es mencionar a alguien en un servidor remoto de lo que parece?

Mastodon recorta cada mención a su parte local antes de contar, así que @someone@long.server.example.org cuesta ocho caracteres en lugar de los 32 que se ven en el editor. Una respuesta en un hilo con varios participantes remotos puede parecer larga en el editor, pero cuesta mucho menos contra el límite de lo que sugiere el texto visible.

¿Hasta dónde llega el límite de caracteres en los servidores reales de Mastodon?

todon.eu reporta 13.120 caracteres a través de su endpoint /api/v2/instance e infosec.exchange reporta 11.000, frente a los 500 de mastodon.social. Los dos alcanzan esas cifras porque ejecutan un fork con el límite fijado en el entorno, no por ninguna opción que ofrezca Mastodon sin modificar.

¿Por qué Mastodon no ofrece un menú desplegable por servidor para el límite de caracteres?

El desarrollador principal de Mastodon ha desestimado parches que hacen configurable el límite, con el argumento de que la interfaz está diseñada en torno a una sola cifra y de que el nivel básico de funcionalidad debería ser el mismo en todos los servidores. La federación lo agrava, porque el validador de longitud solo se aplica a las publicaciones escritas localmente y todos los demás servidores almacenan y muestran lo que les llega. Los operadores que quieren un límite más largo editan la constante ellos mismos o ejecutan un fork como glitch-soc.