Referência de Tipos MIME

O que é, de fato, um tipo MIME

Um tipo MIME, também chamado de tipo de mídia, é um rótulo curto que diz ao software que tipo de dados um arquivo ou corpo de mensagem contém. Ele nasceu no e-mail (a sigla significa Multipurpose Internet Mail Extensions, ou Extensões Multifuncionais de Correio na Internet), mas hoje aparece em toda parte na web. O formato é sempre tipo/subtipo: uma categoria ampla, uma barra e um formato específico. Assim, text/html significa "texto, em forma de HTML", image/png significa "uma imagem, em forma de PNG", e application/json significa "dados de aplicação, codificados como JSON".

O tipo de nível superior vem de um conjunto fixo mantido pela IANA, o registro oficial: text, image, audio, video, application, font, model, multipart e alguns mais recentes, como haptics. O subtipo é o formato específico. Fornecedores podem adicionar os seus próprios com um prefixo vnd. (por exemplo, application/vnd.ms-excel), e tipos experimentais usavam historicamente um prefixo x-, embora essa convenção seja hoje desencorajada.

Onde os tipos MIME importam

O lugar mais importante em que um tipo MIME aparece é o cabeçalho de resposta HTTP Content-Type. Quando um servidor envia uma página, uma imagem ou uma carga útil de API, esse cabeçalho diz ao navegador como interpretar os bytes. Se o cabeçalho diz text/html, o navegador renderiza a marcação; se diz application/json, uma chamada fetch() consegue analisá-la; se diz application/pdf, o visualizador embutido abre. O mesmo cabeçalho também viaja no lado da requisição: quando você envia um formulário ou um corpo de API por POST, o Content-Type diz ao servidor como ler o que você enviou.

Além do HTTP, os tipos MIME movem vários outros sistemas. Os clientes de e-mail os usam para decidir se um anexo é uma imagem para pré-visualizar ou um binário para salvar. Os manipuladores de upload de arquivos inspecionam o tipo declarado para aceitar ou rejeitar arquivos. E o sistema operacional ou o navegador usa o tipo, não apenas a extensão do arquivo, para escolher um aplicativo padrão. A mesma ideia sustenta a forma como servidores relatam resultados e erros junto com os códigos de status HTTP — uma resposta 200 com o tipo errado pode estar tão quebrada quanto um 404.

Os que você vai usar todos os dias

Um punhado de tipos cobre a esmagadora maioria do tráfego real:

• text/html — páginas web (extensão .html)
• text/css — folhas de estilo (.css)
• text/javascript — o tipo recomendado para JavaScript (.js, .mjs)
• application/json — o único tipo JSON oficial, definido na RFC 8259 (.json)
• image/png, image/jpeg, image/webp, image/svg+xml — formatos de imagem comuns
• application/pdf — documentos PDF (.pdf)
• application/octet-stream — o tipo coringa para dados binários desconhecidos ou arbitrários
• text/plain — o padrão para texto simples que não tem um tipo mais específico

O JSON merece uma observação porque confunde as pessoas. O único tipo correto é application/json. Código mais antigo às vezes usava text/json, text/plain ou application/x-javascript, mas esses estão obsoletos e alguns clientes se recusarão a analisá-los. Também não há parâmetro de charset para JSON — a especificação exige UTF-8, então escrever application/json; charset=utf-8 é redundante, embora inofensivo. Para uma tabela mais completa de formatos e extensões, consulte nossas tabelas de referência.

Por que um Content-Type errado quebra as coisas

Navegadores e clientes confiam no tipo declarado, então errá-lo tem consequências concretas. Sirva uma resposta de API JSON como text/html e o navegador pode tentar renderizá-la, ou um cliente rigoroso pode lançar um erro de análise antes mesmo de o seu código rodar. Sirva um arquivo CSS ou JavaScript com o tipo errado e um recurso de segurança chamado X-Content-Type-Options: nosniff fará o navegador se recusar a aplicá-lo, quebrando silenciosamente o estilo ou os scripts da sua página.

Os downloads são a outra falha clássica. Se você quer que um arquivo seja baixado em vez de exibido, o tipo importa junto com o cabeçalho Content-Disposition. Um PDF enviado como application/octet-stream é baixado como um arquivo genérico em vez de abrir no visualizador; uma imagem enviada como text/plain aparece como caracteres ilegíveis. No lado do upload, um arquivo com rótulo errado pode passar despercebido por uma verificação ingênua de extensão, e é por isso que validadores robustos inspecionam os bytes reais (o "número mágico") em vez de confiar no tipo informado pelo cliente.

Historicamente, os navegadores tentavam adivinhar, ou "farejar", o tipo real quando o cabeçalho parecia errado. Esse comportamento causava brechas de segurança, então a melhor prática moderna é sempre enviar um Content-Type preciso e desativar o farejamento com nosniff. Em resumo: defina o tipo deliberadamente em cada resposta e a maioria dos bugs de renderização, download e análise desaparece.

Perguntas frequentes