Content-Type no desenvolvimento web: o que é, tipos MIME e como funciona

O que é Content-Type?

Content-Type é um cabeçalho HTTP do grupo de cabeçalhos de representação que informa ao destinatário o formato dos dados no corpo da mensagem. É obrigatório para solicitações e respostas HTTP que contêm um corpo, e sem ele o cliente não pode interpretar corretamente os bytes recebidos. Com base no Content-Type, o navegador ou aplicativo móvel seleciona um analisador: para text/html inicia o mecanismo HTML, para image/png — o decodificador PNG, para application/json — o analisador JSON.

O valor de Content-Type é um tipo MIME — um identificador padronizado para formatos de dados. A sigla MIME significa Multipurpose Internet Mail Extensions, pois este padrão foi originalmente criado para anexos de e-mail. No entanto, tornou-se a base do HTTP e hoje é usado em toda parte — desde a transmissão de páginas web até a troca de dados em APIs REST. Cada tipo MIME consiste em duas partes: uma categoria principal e um subtipo qualificador, separados por uma barra.

O parâmetro charset complementa o Content-Type para formatos de texto. Por exemplo, Content-Type: text/html; charset=utf-8 indica que um documento HTML está sendo transmitido em codificação UTF-8. De acordo com IETF RFC 7231, seção 3.1.1.5, o cabeçalho Content-Type é obrigatório para mensagens HTTP que contêm um corpo, e sua ausência é tratada como application/octet-stream ou leva a MIME sniffing.

História dos tipos MIME no HTTP

O protocolo HTTP/0.9, lançado em 1991, transmitia apenas páginas HTML, então o tipo de dados estava implícito por padrão. Com a introdução do HTTP/1.0 na RFC 1945, os desenvolvedores perceberam a necessidade de transmitir imagens, folhas de estilo e scripts. Eles adaptaram o padrão MIME do protocolo de e-mail, e o Content-Type tornou-se parte integrante do HTTP. Desde então, o registro IANA expandiu-se para centenas de valores — do familiar text/html aos modernos image/avif e application/manifest+json.

O papel do Content-Type na segurança

Content-Type desempenha um papel crítico na proteção contra ataques. Se um servidor enviar um arquivo HTML com tipo MIME text/plain, o navegador não executará JavaScript nem construirá o DOM — isso previne ataques XSS. O cabeçalho X-Content-Type-Options: nosniff, recomendado pela OWASP, proíbe completamente o navegador de adivinhar o tipo MIME com base no conteúdo. De acordo com PortSwigger Research, ataques de MIME sniffing foram especialmente prevalentes no Internet Explorer 6-9, onde o navegador ignorava o Content-Type e determinava o tipo pelos primeiros bytes do arquivo.

Estrutura do tipo MIME

Um tipo MIME é especificado no formato type/subtype, onde type é a categoria geral de dados e subtype é o formato específico dentro dela. Por exemplo, em image/png, a categoria image indica uma imagem e o subtipo png especifica o formato Portable Network Graphics. Existem apenas algumas categorias: text, image, audio, video, application, multipart e message. O resto da diversidade vem dos subtipos, dos quais existem centenas.

Parâmetros adicionais são passados por ponto e vírgula após o subtipo. O parâmetro mais comum é charset para especificar a codificação. Content-Type: application/json; charset=utf-8 indica que um documento JSON está sendo transmitido em codificação UTF-8. Formalmente, charset para application/json é redundante pois JSON está sempre em UTF-8 de acordo com RFC 8259, mas a especificação explícita melhora a compatibilidade com clientes HTTP antigos.

Tipos MIME padrão e não padrão

Tipos MIME padrão são registrados no registro IANA e têm um prefixo de categoria principal. Tipos não padrão (específicos de fornecedor) usam o prefixo x- ou o formato vnd.company.type — por exemplo, application/vnd.google-earth.kml+xml para o formato KML do Google. Navegadores podem não reconhecer tipos não padrão, portanto, para anexos desconhecidos, usa-se application/octet-stream — um fluxo binário universal que o navegador não tenta exibir, mas oferece para baixar como arquivo.

O parâmetro charset na prática

O parâmetro charset é crítico para a exibição correta de texto. Sem ele, o navegador pode interpretar mal os caracteres, levando a mojibake. O padrão para a web é UTF-8, mas também são encontrados ISO-8859-1 (Latin-1) para idiomas da Europa Ocidental e windows-1251 para cirílico em sites antigos. A recomendação W3C é sempre especificar charset=utf-8 para text/html e text/plain, enquanto charset não é necessário para application/json.

Tipos comuns de Content-Type

Na prática, desenvolvedores web e móveis trabalham com um conjunto limitado de tipos MIME. Conhecer esses tipos é essencial para configurar corretamente servidores, escrever clientes HTTP e manipular arquivos estáticos. text/html é o tipo principal para páginas web, retornado pelos servidores Apache e Nginx por padrão para arquivos HTML. application/xhtml+xml é usado com menos frequência e apenas para documentos XHTML.

application/json tornou-se o padrão para APIs REST. Servidores retornam dados JSON com este tipo MIME, e clientes o enviam em solicitações POST e PUT. text/javascript (obsoleto) e application/javascript são usados para arquivos JavaScript. De acordo com a Pesquisa W3Techs, 2025, JSON é o formato de dados que mais cresce na web, ultrapassando XML em 2018. Para serviços SOAP, ainda são usados text/xml ou application/soap+xml.

Para imagens, o tipo MIME é determinado pelo formato do arquivo: image/jpeg para JPEG, image/png para PNG, image/gif para GIF, image/webp para o formato moderno WebP. image/svg+xml é usado para gráficos vetoriais e suporta estilos e scripts embutidos. video/mp4, audio/mpeg e application/pdf são outros tipos frequentemente encontrados. Para fontes web, são usados font/woff2, font/woff e font/ttf.

Content-Type no upload de arquivos

Ao enviar arquivos através de um formulário HTML, usa-se multipart/form-data — um tipo MIME composto que divide a solicitação em várias partes. Cada parte tem seu próprio cabeçalho Content-Type e Content-Disposition especificando o nome do campo e o nome original do arquivo. O servidor recebe o arquivo com seu tipo MIME real determinado pelo navegador e pode verificá-lo no lado do backend. application/octet-stream é usado para arquivos de tipo desconhecido — o navegador não tenta exibir o conteúdo, mas oferece salvá-lo em disco.

Impacto do Content-Type no cache

O tipo MIME afeta a política de cache de CDN e navegadores. Imagens com URLs estáveis geralmente são armazenadas em cache por um longo período (um ano ou mais), enquanto páginas HTML são armazenadas em cache por minutos ou segundos. Servidores CDN como Cloudflare e Akamai usam Content-Type para selecionar o algoritmo de compressão: text/* é comprimido com gzip ou brotli, image/* não, pois as imagens já estão comprimidas. A configuração correta de Content-Type no servidor impacta diretamente o desempenho de carregamento de páginas web e aplicativos móveis.

Como servidor e cliente usam Content-Type

O servidor define o cabeçalho Content-Type na resposta HTTP com base no tipo do arquivo solicitado ou conteúdo gerado dinamicamente. Servidores web populares como Nginx e Apache têm tabelas de tipos MIME embutidas que mapeiam extensões de arquivo para o Content-Type correspondente. Por exemplo, index.html recebe text/html e style.css recebe text/css. Para respostas dinâmicas, o desenvolvedor define Content-Type no código da aplicação em PHP, Python, Java ou Kotlin.

O cliente usa Content-Type para selecionar um manipulador. Se o servidor retornar text/html, o navegador inicia o analisador HTML e constrói a árvore DOM. Se image/png — inicia o decodificador PNG. Se Content-Type estiver ausente ou incorreto, o cliente aplica MIME sniffing — tenta adivinhar o tipo pela assinatura (bytes mágicos) no início do arquivo. JPEG começa com os bytes FF D8 FF, PNG começa com 89 50 4E 47 e PDF começa com 25 50 44 46. Este processo é potencialmente perigoso e é desativado pelo cabeçalho X-Content-Type-Options: nosniff.

Em aplicativos móveis, Content-Type é manipulado por clientes HTTP. OkHttp no Android analisa automaticamente o cabeçalho Content-Type da resposta e o fornece através do método Response.header("Content-Type"). O cliente URLSession do iOS faz o mesmo através da propriedade URLResponse.mimeType. Em ambas as plataformas, Content-Type é usado para selecionar um analisador: JSON — via Moshi ou Gson no Android, via Codable no iOS; imagens — via Glide, Coil ou SDWebImage.

Negociação de conteúdo via Accept e Content-Type

Negociação de conteúdo é um mecanismo HTTP onde o cliente especifica o formato de resposta desejado através do cabeçalho Accept, e o servidor seleciona o formato apropriado e o retorna com o Content-Type correspondente. Por exemplo, o cliente envia Accept: application/json, o servidor responde com Content-Type: application/json. Se o servidor não puder fornecer o formato solicitado, ele retorna 406 Not Acceptable. Em APIs REST, este mecanismo permite que um único endpoint retorne dados em JSON, XML ou HTML.

Content-Type em solicitações e respostas

O cabeçalho Content-Type é usado tanto em solicitações HTTP quanto em respostas HTTP. Em solicitações, especifica o formato do corpo da solicitação, por exemplo ao enviar JSON via POST. Em respostas, especifica o formato dos dados retornados. A diferença principal é que o Content-Type da solicitação é definido pelo cliente, enquanto o Content-Type da resposta é definido pelo servidor. Definir incorretamente Content-Type em uma solicitação faz com que o servidor não consiga analisar o corpo, retornando um erro 400 Bad Request ou 415 Unsupported Media Type.

Em solicitações HTTP, Content-Type é obrigatório para métodos POST, PUT e PATCH se a solicitação contiver um corpo. GET, HEAD e DELETE tipicamente não usam um corpo, então Content-Type não é especificado ou é ignorado para eles. Ao enviar um formulário HTML com o atributo enctype="multipart/form-data", o navegador define automaticamente Content-Type: multipart/form-data com uma string de limite única que separa as partes da solicitação composta. Cada parte é separada por --boundary, e o fim da solicitação é marcado por --boundary--.

Em respostas HTTP, Content-Type é definido pelo servidor. Se o servidor não especificar Content-Type, o cliente ativa MIME sniffing ou processa a resposta como application/octet-stream. O método HTTP HEAD permite obter cabeçalhos de resposta, incluindo Content-Type, sem transmitir o corpo. Isso é útil para verificar o tipo de recurso antes de carregá-lo completamente. Servidores CDN podem substituir Content-Type ao transformar conteúdo — por exemplo, ao converter imagens para WebP.

import okhttp3.*

fun checkContentType() {
    val client = OkHttpClient()
    val request = Request.Builder()
        .url("https://api.example.com/resource")
        .head()
        .build()

    client.newCall(request).execute().use { response ->
        val contentType = response.header("Content-Type")
        val mediaType = MediaType.parse(contentType)
        println("Tipo: ${mediaType?.type}, Subtipo: ${mediaType?.subtype}")
    }
}

Content-Type em clientes HTTP móveis

No desenvolvimento móvel, o cabeçalho Content-Type é manipulado automaticamente por clientes HTTP. No OkHttp no Android, Content-Type é definido via RequestBody: val body = "{}".toRequestBody("application/json".toMediaType()). Retrofit gerencia Content-Type através de anotações: @Body para JSON, @Part para multipart. No iOS, URLSession define Content-Type para HTTPBody, e Alamofire faz isso através do parâmetro encoding: JSONEncoding.default ou URLEncoding.default. A definição manual de Content-Type é necessária ao trabalhar com sockets brutos ou protocolos personalizados.

Erros de Content-Type

Content-Type incorreto é um dos problemas mais comuns no desenvolvimento e integração de serviços web. O erro mais frequente é quando o servidor retorna text/html em vez de application/json. O cliente recebe JSON como uma string HTML, não consegue analisá-la e lança uma exceção. Isso acontece quando o framework web está configurado para HTML por padrão e o desenvolvedor esquece de substituir Content-Type para endpoints de API. Em PHP isso se manifesta quando header('Content-Type: application/json') está ausente, em Spring Boot — quando a anotação produces está ausente.

O segundo erro mais comum é charset incorreto ou ausente. Se o servidor enviar text/html; charset=iso-8859-1 e o navegador esperar UTF-8, caracteres cirílicos são exibidos como mojibake. Este problema é típico de sites antigos que não migraram para UTF-8. Para JSON, esse erro é menos comum pois RFC 8259 prescreve UTF-8 sem negociação adicional. A solução é sempre especificar explicitamente charset=utf-8 para tipos MIME de texto na configuração do servidor.

O terceiro problema é a discrepância entre Content-Type e o conteúdo real. Se o servidor enviar Content-Type: image/png mas o corpo da resposta contiver uma imagem WebP, o navegador pode não decodificá-la. Servidores CDN às vezes comprimem imagens alterando o formato mas sem atualizar o cabeçalho Content-Type. Verificar Content-Type contra o conteúdo real é uma etapa obrigatória nos testes de API e nos testes de integração de aplicativos móveis.

Diagnóstico e correção de erros de Content-Type

Para depuração, use ferramentas de desenvolvedor do navegador (aba Network), curl com a flag -I para verificar cabeçalhos de resposta, ou sniffers de tráfego como Charles Proxy e Wireshark. Nginx é configurado através da diretiva include mime.types, Apache — através de AddType e AddDefaultCharset. Para arquivos estáticos, sempre verifique se a extensão do arquivo corresponde ao seu tipo MIME. Para respostas dinâmicas em todas as linguagens de programação, defina explicitamente Content-Type antes de gerar dados — isso previne a grande maioria dos problemas.