Referência MIME / Content-Type
ReferênciaTabela de tipos MIME comuns e as respetivas extensões de ficheiro, com pesquisa.
| Content-Type | Extensões | Categoria | Descrição |
|---|
Nesta página
O que é uma referência de tipos MIME?#
Um tipo MIME (também chamado de tipo de mídia ou Content-Type) é o rótulo curto que diz ao receptor que tipo de bytes um documento contém: text/html é uma página web, application/json é dados JSON, image/png é uma imagem PNG. O formato é sempre tipo/subtipo — uma categoria ampla, uma barra, e depois um nome específico. O HTTP depende desses rótulos para decidir se renderiza, baixa, analisa ou rejeita uma resposta; navegadores dependem deles para escolher o manipulador certo (uma <img> espera um tipo de imagem, uma <script> espera um tipo JavaScript); o e-mail depende deles para anexar arquivos.
O formato parece simples, mas o cenário é genuinamente confuso. Existem sete categorias de topo (application, audio, font, image, model, text, video), muitos arquivos correspondem a várias extensões (.jpg, .jpeg, .jpe são todos image/jpeg), alguns tipos têm uma forma antiga e uma moderna (application/javascript versus text/javascript), e escolher o errado causa bugs reais — uma folha de estilo servida como text/plain não se aplica, uma fonte servida como application/octet-stream não carrega. Esta página é uma consulta pesquisável para que você sempre escolha o rótulo certo.
Como usar#
- Pesquise por qualquer coisa. A caixa de Pesquisa filtra a tabela inteira. Três formas de consultar:
- Digite uma extensão de arquivo com um ponto à frente —
.jpg,.woff2,.mp4— e você recebe exatamente os tipos mapeados àquela extensão. - Digite o tipo ou subtipo em si —
image,json,svg— para estreitar por nome. - Digite uma palavra —
archive,font,spreadsheet— para buscar nas descrições.
- Digite uma extensão de arquivo com um ponto à frente —
- Leia a linha. As colunas são Content-Type (o
tipo/subtipocompleto), Extensões (os sufixos comuns de arquivo mapeados a ele), Categoria (um dos sete grupos de topo) e Descrição (uma nota de uma linha sobre para que serve o tipo). - Escolha o certo. Para uma dada extensão costuma haver um tipo canônico; onde existem dois (o caso do JavaScript é o clássico), a descrição explica qual é o atual.
Principais funcionalidades#
- Sete categorias, uma tabela. Tipos application, audio, font, image, model, text e video convivem, para que você possa saltar de uma pergunta sobre fonte a uma pergunta sobre vídeo sem trocar de página.
- Consulta com foco na extensão. A tarefa real comum é “tenho um arquivo
.xlsx, o que defino como Content-Type?” — digitar.xlsxpousa diretamente emapplication/vnd.openxmlformats-officedocument.spreadsheetml.sheet. - Tanto os nomes modernos quanto os antigos. Onde um tipo tem uma forma antiga ainda vista no mundo real, ambos são listados com uma nota, para que você reconheça qualquer direção dum cabeçalho HTTP.
- Tipos de fornecedor incluídos. Microsoft Office, ZIP, gzip, 7z, RAR, WebAssembly, Web App Manifest, GraphQL — as formas longas
application/vnd.*eapplication/*+json/application/*+xmlestão todas lá. - Local e instantâneo. O conjunto de dados está embutido na página; toda pesquisa é um filtro do lado do cliente sem requisição.
Exemplo prático#
JavaScript é a entrada mais confusa de todas, porque o tipo mudou de nome ao longo dos anos e os servidores ainda enviam ambos. Pesquise javascript e você recebe duas linhas:
text/javascript—js,mjs— “the standard, modern MIME type.”application/javascript—js— “legacy JavaScript MIME type (still widely seen).”
A versão curta: text/javascript é o que os padrões atuais de HTML e Fetch mandam você usar, e o que servidores modernos emitem; application/javascript é o nome antigo da RFC 4329 que você ainda verá em cabeçalhos Content-Type mais antigos e em documentação mais antiga. Eles significam a mesma coisa e os navegadores os tratam de forma idêntica — mas para uma nova configuração de servidor, prefira text/javascript.
Mais algumas consultas que valem a pena memorizar, todas a uma pesquisa de distância:
.json→application/json.svg→image/svg+xml(é uma imagem, mas o sufixo+xmlsinaliza que é baseada em XML).woff2→font/woff2(repare na categoria dedicada de topofont/, nãoapplication/).wasm→application/wasm(binário WebAssembly — deve ser servido exatamente assim, sem charset, ou não compila).pdf→application/pdf
Quando um tipo é desconhecido, os servidores voltam para application/octet-stream — o tipo genérico de “isto são alguns dados binários, não assumem nada”. Os navegadores costumam responder baixando o arquivo em vez de tentar exibi-lo.
FAQ#
text/javascript ou application/javascript — qual uso?#
Para código novo, envie text/javascript. É o que as especificações atuais de HTML e Fetch da WHATWG exigem, e o que os navegadores de fato verificam ao decidir se executam uma <script>. application/javascript ainda funciona em todo lugar (é o padrão mais antigo), mas é a forma legada. Se você está configurando um servidor novo, base de dados mime ou ferramenta de build, use text/javascript como padrão.
Por que o SVG tem +xml no tipo?#
O sufixo +xml é um sufixo de sintaxe estruturada: diz-lhe que a serialização do tipo é XML por baixo. Então image/svg+xml significa “uma imagem, especificamente uma descrita em XML”. A mesma convenção aparece em application/ld+json (dados ligados, serializados em JSON) e application/graphql+json. Ferramentas que entendem o sufixo podem voltar a um parser XML ou JSON genérico.
Para que serve application/octet-stream?#
É a opção coringa para “dados binários arbitrários, tipo desconhecido”. Os servidores o retornam quando não conseguem identificar um arquivo, e o comportamento seguro do cliente é baixá-lo em vez de tentar renderizá-lo ou executá-lo. Se algum dia você vir um arquivo que esperava abrir no navegador começar a baixar em vez disso, um Content-Type errado ou ausente (colapsando para octet-stream) é o culpado habitual.
Como eu realmente defino um Content-Type nos meus arquivos?#
Isso depende de onde o arquivo é servido — um servidor de arquivos estáticos o lê a partir da extensão via uma base de dados mime, um framework web o define em código (frequentemente response.setContentType(...) ou uma atribuição de cabeçalho), e uma CDN o expõe no upload ou nos metadados do objeto. A chamada exata difere por stack; a única coisa que tem de estar certa é a string final na transmissão, que é exatamente o que esta consulta lhe dá.