SRT vs VTT vs TTML: tres formatos, tres trabajos

Three Formats, Three Jobs

SRT es para la portabilidad, VTT es para la web, TTML es para la emisión y la entrega OTT. Si alguna vez has subido un archivo de subtítulos y has visto cómo falla en silencio, te has topado con este desajuste. Los tres formatos se parecen por fuera, pero resuelven problemas distintos, y la mayoría de las plataformas solo aceptan uno o dos.

Esta entrada asigna cada formato a su función real: cómo es su estructura, qué reproductores y plataformas lo aceptan, y en qué puntos las especificaciones de entrega OTT divergen de maneras que importan si tu contenido acaba en Netflix, Amazon o Disney+. Para la elección más sencilla entre dos formatos, la de SRT y WebVTT, la comparativa SRT vs VTT profundiza más sin el contexto de la emisión.

SRT: El mínimo común denominador

SRT (SubRip) es el más antiguo de los tres y el formato con mayor soporte que existe. Un archivo SRT básico tiene este aspecto:

1
00:00:01,000 --> 00:00:04,500
Este es el primer subtítulo.

2
00:00:05,000 --> 00:00:08,200
Este es el segundo subtítulo.

Cada bloque tiene un número de secuencia, un rango de tiempos que usa una coma como separador de milisegundos, y una o dos líneas de texto. Esa coma no es casual: SRT se creó en Europa, donde la coma es el separador decimal. Cuando alguien convierte SRT a VTT a mano y olvida cambiar las comas por puntos, el archivo falla en silencio en los navegadores.

Las fortalezas de SRT van de la mano de sus limitaciones. El formato es tan sencillo que cualquier reproductor de vídeo en cualquier sistema operativo lo lee: YouTube, Vimeo, VLC, Plex, Premiere Pro, DaVinci Resolve y la mayoría de los codificadores de nivel profesional. Si solo puedes enviar un formato, envía SRT.

Las debilidades son la falta de estilo nativo y la limitación de un solo idioma por archivo. Si necesitas texto en negrita, color, posicionamiento en pantalla o atribución de hablante dentro de los propios datos del subtítulo, SRT no puede transportarlo. La mayoría de los flujos de trabajo que requieren subtítulos con estilo queman el texto en los píxeles del vídeo, algo que la guía del generador de subtítulos cubre por separado.

VTT: el estándar web moderno

WebVTT es el formato que el W3C creó para vídeo HTML5, y es el que todos los navegadores modernos entienden de forma nativa. La estructura es paralela a la de SRT, pero usa un punto como separador de milisegundos e incluye soporte explícito para estilo, posicionamiento y metadatos de hablante:

WEBVTT

00:00:01.000 --> 00:00:04.500 line:90% align:center
<v Alice>Este es el primer subtítulo.

00:00:05.000 --> 00:00:08.200
<v Bob>Este es el segundo subtítulo.

Las etiquetas <v Alice> y <v Bob> son anotaciones de voz del hablante, lo que significa que un archivo VTT puede llevar datos de diarización de serie. Los ajustes de señal line:90% align:center indican al reproductor dónde renderizar el texto en pantalla. También puedes adjuntar CSS mediante el pseudo-elemento ::cue para color, tamaño de fuente y fondo.

VTT es obligatorio si usas el elemento <track> de HTML5 para adjuntar subtítulos a una etiqueta <video> en tu propio sitio. Todos los navegadores modernos lo leen de forma nativa. Los reproductores JavaScript como Video.js y Plyr están construidos alrededor de VTT. Si publicas vídeo web, este es el formato que quieres.

Donde VTT encuentra problemas es en destinos que no son web. YouTube sí acepta VTT (junto con SRT, SBV, TTML y DFXP), pero la mayoría de los codificadores de consumo y las herramientas de radiodifusión usan SRT por defecto o exigen TTML. Convierte desde el formato que hayas generado primero; el intercambio de códigos de tiempo es la única tarea técnica.

TTML: el formato de radiodifusión y OTT

TTML (Timed Text Markup Language) es lo que exigen los grandes servicios de streaming y las cadenas de televisión en sus entregas, y no es intercambiable con SRT o VTT para esos destinos. El archivo es XML y se ve muchísimo más pesado que los otros dos:

<?xml version="1.0" encoding="UTF-8"?>
<tt xmlns="http://www.w3.org/ns/ttml"
    xmlns:tts="http://www.w3.org/ns/ttml#styling">
  <head>
    <styling>
      <style xml:id="default"
             tts:fontFamily="sansSerif"
             tts:color="white"
             tts:fontSize="100%"/>
    </styling>
  </head>
  <body>
    <div>
      <p begin="00:00:01.000" end="00:00:04.500"
         style="default">This is the first caption.</p>
      <p begin="00:00:05.000" end="00:00:08.200"
         style="default">This is the second caption.</p>
    </div>
  </body>
</tt>

Esa verbosidad compra capacidad real: estilos enriquecidos, varias pistas de idioma en un solo archivo, posicionamiento basado en porcentajes, texto ruby para japonés y metadatos estructurados para auditores de accesibilidad. TTML es una especificación del W3C, pero en la práctica cada plataforma que lo exige usa un perfil concreto.

Los perfiles OTT: Netflix, Amazon, Disney+

Aquí es donde "TTML" deja de ser una respuesta única. Los grandes streamers imponen cada uno un perfil distinto o un conjunto de restricciones.

Netflix exige TTML1 con extensión .xml o .ttml para todos los idiomas. El japonés es la excepción: Netflix requiere el formato IMSC 1.1 específicamente para japonés, con su propio identificador de perfil. Los requisitos generales de TTML1 son estrictos: todos los datos de posición deben usar solo valores porcentuales, nunca píxeles; el tamaño de fuente debe expresarse como 100%; los timecodes dependen de la velocidad de fotogramas de la fuente.

Amazon Prime Video es más permisivo que Netflix. Para subtítulos, acepta STL, DFXP/TTML, SCC y SRT. Para archivos de subtítulos (solo diálogo), acepta DFXP/TTML, iTT (un subconjunto de TTML 1.0 desarrollado por Apple) y SRT. Que acepte SRT en la pista de subtítulos significa que muchos productores pequeños pueden omitir TTML por completo en los envíos a Prime Video Direct.

Disney+ exige IMSC 1.1 como formato general de entrega. Para contenido japonés publica su propio perfil IMSC 1.1 con reglas de validación independientes.

EBU-TT-D es el perfil que desarrolló la Unión Europea de Radiodifusión para distribución por IP y streaming DVB-DASH. Es un subconjunto del Perfil de Texto IMSC 1, con diferencias menores. La plataforma Freely del Reino Unido (el servicio IPTV conjunto de BBC, ITV, Channel 4 y Channel 5, lanzado en 2024) exige EBU-TT-D para todos los reproductores participantes. Si un contrato menciona "EBU-TT-D", está pidiendo un archivo TTML restringido, no un formato completamente distinto.

Mi opinión: si no entregas contenido a una cadena o a una plataforma OTT con nombre propio, casi con total seguridad no necesitas TTML. La complejidad de este formato es un coste que solo compensa cuando una especificación concreta lo exige. Fuera de esos contratos, el resto del sector está bien cubierto con SRT y VTT.

Tabla comparativa de funciones

La clasificación es práctica: SRT para la máxima cobertura, VTT para vídeo HTML5, TTML cuando un contrato exige un perfil concreto.

Conversión: qué se pierde en cada dirección

Convertir entre los tres formatos es en su mayoría mecánico, pero la conversión no es simétrica.

De SRT a VTT es casi sin pérdidas. Añade una cabecera WEBVTT en la primera línea y cambia todas las comas de los timecodes por puntos. La estructura de bloques permanece idéntica. Si quieres etiquetas de hablante, añade anotaciones <v Name> a mano o desde una fuente de transcripción diarizada.

De SRT o VTT a TTML añade estructura que luego hay que rellenar. Los timecodes se transfieren sin problemas. Los atributos de estilo están vacíos (requieren que un ingeniero de localización los complete) o se autocompletan con una herramienta de conversión. El perfil de plataforma casi nunca lo gestionan los convertidores genéricos: tendrás que añadir el designador de perfil, los tamaños de fuente solo en porcentaje y cualquier modo de timecode basado en fotogramas que exija la especificación. Prevé una pasada de control de calidad después de cualquier conversión a TTML.

TTML to SRT es un proceso con pérdida. El estilo, el posicionamiento y las pistas multilingüe se pierden por completo. El SRT resultante tendrá texto plano con códigos de tiempo correctos, que suele ser justo lo que necesita una subida a YouTube.

Un detalle de sincronización que merece la pena mencionar: las conversiones de TTML a veces eliminan la precisión de milisegundos cuando la fuente usa modos de código de tiempo con diferente velocidad de fotogramas (SMPTE frente a tiempo de medios). Si los subtítulos parecen desfasados un fotograma después de la conversión, la causa es el modo de código de tiempo, no el contenido.

Los dos escenarios más comunes en la práctica:

1. Un cliente entrega un SRT y tu emisora exige TTML para cumplir una especificación de entrega. Convierte, añade los campos de metadatos necesarios y valida contra la especificación. El generador de subtítulos puede crear un SRT a partir de audio si necesitas empezar desde cero.
2. Una emisora entrega un TTML y necesitas un SRT para una subida a YouTube o un reproductor web. Convierte y asume la pérdida de estilo. El texto y la sincronización serán correctos.

Realidad de las plataformas

Esto es lo que acepta realmente cada destino principal, verificado contra la documentación actual de cada plataforma:

• YouTube: SRT, VTT, SBV, TTML, DFXP, SCC y varios formatos de emisión heredados a través de YouTube Studio.
• Vimeo: SRT y VTT.
• Facebook e Instagram: solo SRT mediante las herramientas de subida para creadores. La mayoría del contenido de formato corto quema los subtítulos en el vídeo.
• TikTok: no permite subir archivos de subtítulos externos. Hay que quemarlos en el vídeo.
• Netflix: TTML1 (.xml/.ttml) para todos los idiomas; IMSC 1.1 para japonés. Todos los datos de posición deben usar solo valores porcentuales.
• Amazon Prime Video: DFXP/TTML, iTT y SRT para pistas de subtítulos.
• Disney+: IMSC 1.1.
• Emisión europea / DVB-DASH: EBU-TT-D (un subconjunto restringido de TTML).
• Vídeo HTML5 en tu propio sitio: VTT mediante el elemento <track>.

Si publicas en más de un destino, genera primero un SRT limpio y convierte a partir de ahí. Editar XML a mano es lento; editar un SRT en texto plano y volver a convertir lleva segundos.

Elegir el formato inicial adecuado

For the majority of use cases, generate SRT first. You can export SRT directly from any transcription, edit errors in a plain text editor, upload to YouTube, and attach to a video file. If your destination is an HTML5 player on your own site, switch the export to VTT. If a broadcaster or OTT platform is in the delivery chain, convert from your SRT source once you have confirmed the exact profile the spec requires.

The format is rarely the bottleneck. Accuracy, readable line breaks, and correct timing are what viewers notice. Once those are right, format conversion is a step measured in seconds. ConvertAudioToText generates SRT and VTT directly from any audio or video file, giving you a clean source to work from. For TTML delivery, use that SRT as the conversion input rather than converting from a rough draft.

Common Questions

What is the difference between SRT and VTT?

SRT uses a comma as the millisecond separator in timecodes (00:00:01,000) and has no header line. VTT uses a period (00:00:01.000) and starts with a WEBVTT header. VTT also supports speaker voice tags, percentage-based positioning, and CSS styling. For HTML5 web video, VTT is the right choice. For maximum cross-platform compatibility, SRT reaches further. The SRT vs VTT comparison covers the two-format decision in detail.

Does Netflix require TTML or IMSC?

Netflix requires TTML1 (file extension .xml or .ttml) for all subtitle and SDH deliverables in most languages. IMSC 1.1 is required for Japanese content specifically, under Netflix's own IMSC 1.1 profile. The two are related: IMSC is a constrained TTML profile, but the naming in Netflix specs is specific. Confirm the exact profile against your current Netflix partner delivery documentation before submitting.

Can I convert SRT to TTML automatically?

Sí, pero con matices. Los conversores genéricos transfieren los códigos de tiempo y el texto con precisión. Sin embargo, normalmente no completan el designador de perfil específico de la plataforma, el tamaño de fuente basado únicamente en porcentajes ni el modo de código de tiempo basado en fotogramas que exige una especificación OTT concreta. Tras cualquier conversión automática de SRT a TTML, es obligatorio realizar una verificación de control de calidad contra la especificación de destino antes de la entrega.

¿Qué formato debería usar para YouTube?

SRT y VTT funcionan ambos en YouTube. La plataforma acepta los dos, junto con varios otros formatos. SRT es la opción más habitual porque es la salida de casi todas las herramientas de transcripción y resulta más sencillo de editar manualmente. VTT funciona igual de bien si es lo que produce tu flujo de transcripción. Para subtítulos de YouTube específicamente, el generador de subtítulos produce cualquiera de los dos formatos a partir de una subida de audio o vídeo.

Fuentes

• Centro de ayuda para socios de Netflix: Guía de estilo general para texto con marcas de tiempo
• Centro de ayuda para socios de Netflix: Perfil de texto IMSC 1.1 de Netflix
• Amazon Prime Video Direct: Requisitos de subtítulos
• Ayuda de YouTube: Archivos de subtítulos y subtítulos ocultos compatibles
• W3C: WebVTT: El formato de pistas de texto para vídeo web
• W3C: Perfiles TTML para subtítulos e intertítulos en Internet (IMSC 1.2)
• MDN Web Docs: IMSC: Subtítulos e intertítulos para la web
• DVB: Sistemas de subtitulado DVB-TTML