SRT vs VTT vs TTML: Três Formatos, Três Funções
legendasformatoscomparação

SRT vs VTT vs TTML: Três Formatos, Três Funções

BMMamane B. MoussaMay 26, 2026Updated July 2, 202612 min read

Summarize this article with:

TL;DR

SRT é para portabilidade (quase toda plataforma aceita, sem estilos), VTT é para a web (players HTML5, com estilos e posicionamento), e TTML é para broadcast e OTT (Netflix e Amazon exigem perfis TTML/IMSC). Converter para SRT remove estilos; converter para cima não adiciona nada automaticamente. Crie no formato mais rico que seu fluxo precisar e exporte conforme cada plataforma de destino exigir.

Três Formatos, Três Funções

SRT é para portabilidade, VTT é para a web, TTML é para transmissão e entrega OTT. Se você já enviou um arquivo de legenda e viu ele falhar silenciosamente, você esbarrou nessa incompatibilidade. Os três formatos parecem parecidos por fora, mas resolvem problemas diferentes, e a maioria das plataformas só aceita um ou dois.

Este post mapeia cada formato para sua função no mundo real: como ele é estruturalmente, quais players e plataformas o aceitam, e onde as especificações de entrega OTT divergem de maneiras que importam se seu conteúdo vai parar na Netflix, Amazon ou Disney+. Para a escolha mais simples entre dois formatos, SRT e WebVTT, a comparação SRT vs VTT aprofunda sem o contexto de transmissão.

SRT: O Mínimo Denominador Comum

SRT (SubRip) é o mais antigo dos três e o formato mais amplamente suportado que existe. Um arquivo SRT básico se parece com isso:

1
00:00:01,000 --> 00:00:04,500
Esta é a primeira legenda.

2
00:00:05,000 --> 00:00:08,200
Esta é a segunda legenda.

Cada bloco tem um número de sequência, um intervalo de timecode usando vírgula como separador de milissegundos, e uma ou duas linhas de texto. Essa vírgula não é acidental: o SRT foi criado na Europa, onde a vírgula é o separador decimal. Quando as pessoas convertem SRT para VTT manualmente e esquecem de trocar vírgulas por pontos, o arquivo falha silenciosamente nos navegadores.

Os pontos fortes do SRT são inseparáveis de seus limites. O formato é tão simples que todo player de vídeo em todo sistema operacional o lê: YouTube, Vimeo, VLC, Plex, Premiere Pro, DaVinci Resolve e a maioria dos codificadores de nível broadcast. Se você só pode enviar um formato, envie SRT.

As fraquezas são a falta de estilização nativa e a limitação de um idioma por arquivo. Se você precisa de texto em negrito, cor, posicionamento na tela ou atribuição de falante nos próprios dados da legenda, o SRT não suporta isso. A maioria dos fluxos de trabalho que exigem legendas estilizadas queima o texto nos pixels do vídeo, o que o guia de gerador de legendas aborda separadamente.

VTT: O Padrão Moderno para a Web

WebVTT é o formato que o W3C criou para vídeo em HTML5, e é o que todo navegador moderno entende nativamente. A estrutura é parecida com a do SRT, mas usa ponto como separador de milissegundos e já vem com suporte explícito para estilização, posicionamento e metadados de falante:

WEBVTT

00:00:01.000 --> 00:00:04.500 line:90% align:center
<v Alice>Esta é a primeira legenda.

00:00:05.000 --> 00:00:08.200
<v Bob>Esta é a segunda legenda.

As tags <v Alice> e <v Bob> são anotações de voz do falante, o que significa que um arquivo VTT pode carregar dados de diarização de fábrica. As configurações de cue line:90% align:center dizem ao player onde renderizar o texto na tela. Você também pode anexar CSS via pseudo-elemento ::cue para cor, tamanho da fonte e fundo.

O VTT é obrigatório se você usa o elemento <track> do HTML5 para anexar legendas a uma tag <video> no seu próprio site. Todo navegador moderno lê isso nativamente. Players em JavaScript como Video.js e Plyr são construídos em torno do VTT. Se você publica vídeo na web, este é o formato que você quer.

O problema do VTT aparece em destinos fora da web. O YouTube aceita VTT (junto com SRT, SBV, TTML e DFXP), mas a maioria dos codificadores de consumo e ferramentas de transmissão usa SRT por padrão ou exige TTML. Converta a partir do formato que você gerou primeiro; a troca de timecode é o único trabalho técnico.

Gere uma vez, exporte no formato que o destino exige
Gere uma vez, exporte no formato que o destino exige

TTML: O Formato para Broadcast e OTT

TTML (Timed Text Markup Language) é o que os principais serviços de streaming e emissoras exigem na entrega, e ele não é intercambiável com SRT ou VTT para esses destinos. O arquivo é XML e parece bem mais pesado que os outros dois:

<?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>

Essa verbosidade compra capacidade real: estilos ricos, múltiplas faixas de idioma em um único arquivo, posicionamento baseado em porcentagem, texto ruby para japonês e metadados estruturados para auditores de acessibilidade. TTML é uma especificação do W3C, mas na prática cada plataforma que exige esse formato usa um perfil específico.

Os Perfis OTT: Netflix, Amazon, Disney+

É aqui que "TTML" deixa de ser uma resposta única. Os grandes streamers cada um manda um perfil diferente ou um conjunto de restrições.

Netflix exige TTML1 com extensão .xml ou .ttml para todos os idiomas. Japonês é a exceção: a Netflix exige o formato IMSC 1.1 especificamente para japonês, com seu próprio identificador de perfil. Os requisitos gerais do TTML1 são rígidos: todos os dados posicionais devem usar apenas valores percentuais, nunca pixels; o tamanho da fonte deve ser expresso como 100%; os timecodes dependem da taxa de quadros da fonte.

Amazon Prime Video é mais permissivo que a Netflix. Para legendas, aceita STL, DFXP/TTML, SCC e SRT. Para arquivos de legenda (somente diálogo), aceita DFXP/TTML, iTT (um subconjunto de TTML 1.0 desenvolvido pela Apple) e SRT. A aceitação de SRT na trilha de legendas significa que muitos produtores menores podem ignorar o TTML por completo nas submissões ao Prime Video Direct.

Disney+ exige IMSC 1.1 como formato geral de entrega. Para conteúdo japonês, publica seu próprio perfil IMSC 1.1 com regras de validação separadas.

EBU-TT-D é o perfil que a União Europeia de Radiodifusão desenvolveu para distribuição via IP e streaming DVB-DASH. É um subconjunto do Perfil de Texto IMSC 1, com pequenas diferenças. A plataforma Freely do Reino Unido (o serviço IPTV conjunto da BBC/ITV/Channel 4/Channel 5, lançado em 2024) exige EBU-TT-D para todos os players participantes. Se um contrato menciona "EBU-TT-D", está pedindo um arquivo TTML restrito, não um formato totalmente diferente.

Minha opinião: se você não está entregando para uma emissora ou plataforma OTT específica, quase certamente não precisa de TTML. A complexidade do formato é um custo que só se justifica quando uma especificação específica exige. Fora desses contratos, o resto da indústria está bem servido com SRT e VTT.

Tabela Comparativa de Recursos

RecursoSRTVTTTTML
Extensão do arquivo.srt.vtt.ttml ou .xml ou .dfxp
Separador de milissegundosVírgula (,)Ponto (.)Ponto (.)
Suporte a playersUniversalNavegadores modernos, players webFerramentas de broadcast e OTT
EstilizaçãoNenhuma (alguns players respeitam tags HTML inline)CSS via ::cueRica, baseada em atributos
Rótulos de falanteNão (apenas gambiarras)Sim, via tags <v Name>Sim, múltiplos mecanismos
PosicionamentoNãoSim, configurações de cue baseadas em porcentagemSim, precisão de pixel ou porcentagem
Múltiplos idiomasUm arquivo por idiomaUm arquivo por idiomaVários em um único arquivo
Entrega OTTNãoNãoSim, via perfis específicos de plataforma
Uso principalPortabilidade universalVídeo web em HTML5Broadcast, OTT, conformidade

A hierarquia é prática: SRT para o maior alcance, VTT para vídeo em HTML5, TTML quando um contrato exige um perfil específico.

Conversão: O Que Você Perde em Cada Direção

Converter entre os três formatos é quase mecânico, mas a conversão não é simétrica.

SRT para VTT é quase sem perdas. Adicione um cabeçalho WEBVTT na primeira linha e troque todas as vírgulas nos timecodes por pontos. A estrutura dos blocos permanece idêntica. Se quiser rótulos de falante, adicione anotações <v Name> manualmente ou a partir de uma transcrição diarizada.

SRT ou VTT para TTML adiciona estrutura que você precisa preencher depois. Os timecodes transferem limpos. Os atributos de estilização ficam em branco (exigindo que um engenheiro de localização preencha) ou são preenchidos automaticamente por uma ferramenta de conversão. O perfil da plataforma quase nunca é tratado por conversores genéricos: você vai precisar adicionar o designador de perfil, os tamanhos de fonte apenas em porcentagem e qualquer modo de timecode baseado em frame rate que a especificação exigir. Planeje uma passada de controle de qualidade após qualquer conversão TTML.

TTML para SRT é um processo com perdas. Estilos, posicionamento e faixas multilíngues são descartados. O SRT resultante terá texto simples com timecodes corretos, o que muitas vezes é exatamente o que um upload para o YouTube precisa.

Uma armadilha de timing que vale mencionar: conversões de TTML às vezes perdem precisão de milissegundos quando a fonte usa modos de timecode com taxas de quadros diferentes (SMPTE vs tempo de mídia). Se as legendas parecerem um quadro desalinhado após a conversão, o modo de timecode é a causa, não o conteúdo.

Os dois cenários mais comuns na prática:

  1. Um cliente entrega um SRT e sua emissora exige TTML para uma especificação de entrega. Converta, adicione os campos de metadados necessários e valide contra a especificação. O gerador de legendas pode produzir SRT a partir de áudio se você precisar começar do zero.
  2. Uma emissora entrega um TTML e você precisa de SRT para um upload no YouTube ou player web. Converta e aceite a perda de estilos. O texto e o timing estarão corretos.

Realidade das Plataformas

Aqui está o que cada destino principal realmente aceita, verificado na documentação atual das plataformas:

  • YouTube: SRT, VTT, SBV, TTML, DFXP, SCC e vários formatos legados de broadcast via YouTube Studio.
  • Vimeo: SRT e VTT.
  • Facebook e Instagram: apenas SRT pelas ferramentas de upload do criador. A maioria do conteúdo curto queima as legendas no vídeo.
  • TikTok: sem upload de arquivo de legenda externo. Queime no vídeo.
  • Netflix: TTML1 (.xml/.ttml) para todos os idiomas; IMSC 1.1 para japonês. Todos os dados de posicionamento devem usar apenas valores percentuais.
  • Amazon Prime Video: DFXP/TTML, iTT e SRT para faixas de legenda.
  • Disney+: IMSC 1.1.
  • Broadcast europeu / DVB-DASH: EBU-TT-D (um subconjunto restrito de TTML).
  • Vídeo HTML5 no seu próprio site: VTT via elemento <track>.

Se você publica em mais de um destino, gere um SRT limpo primeiro e converta depois. Editar XML à mão é lento; editar um SRT em texto simples e reconverter leva segundos.

Escolhendo o Formato Inicial Certo

Para a maioria dos casos de uso, gere o SRT primeiro. Você pode exportar o SRT diretamente de qualquer transcrição, corrigir erros em um editor de texto simples, enviar para o YouTube e anexar a um arquivo de vídeo. Se o destino for um player HTML5 no seu próprio site, mude a exportação para VTT. Se uma emissora ou plataforma OTT estiver na cadeia de entrega, converta a partir do seu SRT de origem assim que confirmar o perfil exato que a especificação exige.

O formato raramente é o gargalo. Precisão, quebras de linha legíveis e timing correto são o que os espectadores notam. Uma vez que isso esteja certo, a conversão de formato é uma etapa que leva segundos. O ConvertAudioToText gera SRT e VTT diretamente de qualquer arquivo de áudio ou vídeo, dando a você uma fonte limpa para trabalhar. Para entrega em TTML, use esse SRT como entrada de conversão em vez de converter a partir de um rascunho bruto.

Perguntas Frequentes

Qual é a diferença entre SRT e VTT?

O SRT usa vírgula como separador de milissegundos nos timecodes (00:00:01,000) e não tem linha de cabeçalho. O VTT usa ponto (00:00:01.000) e começa com um cabeçalho WEBVTT. O VTT também suporta tags de voz do locutor, posicionamento baseado em porcentagem e estilos CSS. Para vídeo web em HTML5, o VTT é a escolha certa. Para máxima compatibilidade entre plataformas, o SRT alcança mais longe. A comparação entre SRT e VTT aborda a decisão entre os dois formatos em detalhe.

A Netflix exige TTML ou IMSC?

A Netflix exige TTML1 (extensão de arquivo .xml ou .ttml) para todas as entregas de legendas e SDH na maioria dos idiomas. O IMSC 1.1 é exigido especificamente para conteúdo em japonês, sob o perfil IMSC 1.1 próprio da Netflix. Os dois são relacionados: IMSC é um perfil TTML restrito, mas a nomenclatura nas especificações da Netflix é específica. Confirme o perfil exato contra a documentação atual de entrega de parceiros da Netflix antes de enviar.

Posso converter SRT para TTML automaticamente?

Sim, mas com ressalvas. Conversores genéricos transferem timecodes e texto com precisão. Normalmente, eles não preenchem o designador de perfil específico da plataforma, o dimensionamento de fonte apenas em porcentagem ou o modo de timecode por taxa de quadros que uma especificação OTT exige. Após qualquer conversão automática de SRT para TTML, uma verificação de controle de qualidade contra a especificação de destino é obrigatória antes da entrega.

Qual formato devo usar no YouTube?

SRT ou VTT funcionam no YouTube. O YouTube aceita ambos, além de vários outros formatos. O SRT é a escolha mais comum porque é a saída de quase toda ferramenta de transcrição e é mais simples de editar manualmente. O VTT funciona igualmente bem se for o que seu fluxo de transcrição produz. Para legendas do YouTube especificamente, o gerador de legendas produz qualquer um dos formatos a partir de um upload de áudio ou vídeo.

Fontes

Try transcription free

Convert any audio or video to clean, unwatermarked text — speaker labels, timestamps, and AI summaries included. First 10 minutes free, no account.

Related Articles