MIME type

Um MIME type (Multipurpose Internet Mail Extensions, agora formalmente apenas “tipo de mídia” conforme o RFC 6838) é um identificador de duas partes no formato tipo/subtipo que informa a um cliente que tipo de dados ele está vendo.

Exemplos comuns:

• text/html — documento HTML
• application/json — dados JSON
• image/png, image/jpeg, image/webp — formatos de imagem
• application/pdf — documento PDF
• multipart/form-data — payload de upload de arquivo
• application/octet-stream — binário opaco; o fallback “são apenas bytes, descubra o que é”

As respostas HTTP carregam MIME types no cabeçalho Content-Type. Data URIs (usadas pela nossa ferramenta de imagem para Base64) incorporam o MIME type diretamente: data:image/png;base64,iVBOR.... Os navegadores usam o MIME type declarado para decidir como renderizar ou baixar um recurso.

Nota histórica: o MIME foi originalmente definido para anexos de e-mail. O mesmo registro agora define tipos de mídia para a web, IM, RSS e a maioria dos protocolos modernos.

O Registro de Tipos de Mídia da IANA: todo MIME type legítimo está registrado na Internet Assigned Numbers Authority. Os tipos de nível superior são fixos (text, image, audio, video, application, multipart, message, model, font, example, mais o prefixo legado X-). Os subtipos são adicionados por meio de um processo de registro IETF ou de árvore de fornecedores; application/vnd.openxmlformats-officedocument.wordprocessingml.document (o MIME type formal para .docx) é um exemplo de árvore de fornecedor. Subtipos desconhecidos padrão para application/octet-stream, o que geralmente aciona um prompt de download no navegador em vez de renderização inline.

MIME sniffing — a armadilha de segurança: se um servidor retornar o Content-Type errado, os navegadores historicamente tentavam adivinhar com base nos primeiros bytes da resposta. Esse “content sniffing” permitia ataques cross-site onde uma imagem enviada pelo usuário poderia ser reinterpretada como HTML ou JavaScript. A correção é X-Content-Type-Options: nosniff, que força o navegador a honrar o tipo declarado e se recusar a executar conteúdo incompatível. Frameworks web modernos enviam este cabeçalho por padrão. Referência: RFC 6838 — Media Type Specifications and Registration Procedures.

Parâmetros: charset, boundary, profile

Um MIME type pode carregar parâmetros após um ponto e vírgula. O mais comum é charset: Content-Type: text/html; charset=utf-8 informa ao navegador que a resposta é HTML codificado como UTF-8. Sem ele, os navegadores recorrem a codificações legadas (Windows-1252 em muitos casos) que distorcem o texto não-ASCII. Para uploads multipart/form-data, o parâmetro boundary especifica o delimitador entre partes: multipart/form-data; boundary=---WebKitFormBoundary7MA4YWxkTrZu0gW. JSON-LD usa um parâmetro profile: application/ld+json; profile="https://www.w3.org/ns/activitystreams". Os parâmetros são insensíveis a maiúsculas para nomes; os valores são insensíveis para a maioria dos parâmetros bem conhecidos, mas sensíveis para o boundary de multipart.

A convenção de sufixo +

O RFC 6839 adicionou uma convenção de sufixo de sintaxe estruturada que permite que novos tipos de mídia declarem qual formato genérico eles analisam como: application/atom+xml, application/vnd.api+json, image/svg+xml. O sufixo diz a um analisador genérico (uma biblioteca XML ou JSON) como ler os bytes mesmo que ele não reconheça o tipo de fornecedor específico. Os padrões web modernos dependem muito disso — todo tipo de mídia de API baseado em JSON termina em +json; todo baseado em XML em +xml. A partir de 2026, o registro da IANA lista mais de 2.300 tipos de mídia registrados em todas as categorias de nível superior, com a árvore application/ (mais de 1.800 entradas) de longe a maior. Referência: IANA Media Types Registry.