Referencia MIME / Content-Type

¿Qué es una referencia de tipos MIME?#

Un tipo MIME (también llamado media type o Content-Type) es la etiqueta corta que le dice al receptor qué tipo de bytes contiene un documento: text/html es una página web, application/json son datos JSON, image/png es una imagen PNG. El formato es siempre tipo/subtipo: una categoría amplia, una barra y luego un nombre específico. HTTP se apoya en estas etiquetas para decidir si renderiza, descarga, analiza o rechaza una respuesta; los navegadores se apoyan en ellas para elegir el manejador adecuado (un <img> espera un tipo de imagen, un <script> espera un tipo de JavaScript); el correo se apoya en ellas para adjuntar archivos.

El formato parece simple, pero el panorama es genuinamente confuso. Hay siete categorías de nivel superior (application, audio, font, image, model, text, video); muchos tipos coinciden con varias extensiones (.jpg, .jpeg, .jpe son todos image/jpeg); algunos tipos tienen una forma antigua y otra moderna (application/javascript frente a text/javascript), y elegir la equivocada provoca errores reales: una hoja de estilos servida como text/plain no se aplicará; una fuente servida como application/octet-stream no cargará. Esta página es una búsqueda rápida para que siempre elijas la etiqueta correcta.

Cómo se usa#

1. Busca por cualquier cosa. La caja de búsqueda filtra toda la tabla. Tres formas de consultar:
   • Escribe una extensión de archivo con un punto inicial (.jpg, .woff2, .mp4) y obtienes exactamente los tipos mapeados a esa extensión.
   • Escribe el tipo o subtipo mismo (image, json, svg) para estrechar por nombre.
   • Escribe una palabra (archive, font, spreadsheet) para buscar en las descripciones.
2. Lee la fila. Las columnas son Content-Type (el tipo/subtipo completo), Extensiones (los sufijos de archivo comunes que se mapean a él), Categoría (uno de los siete grupos de nivel superior) y Descripción (una nota de una línea sobre para qué sirve el tipo).
3. Elige el correcto. Para una extensión dada suele haber un tipo canónico; donde existen dos (el caso de JavaScript es el clásico), la descripción explica cuál es el actual.

Características clave#

• Siete categorías, una tabla. Tipos application, audio, font, image, model, text y video viven juntos, así que puedes saltar de una pregunta sobre fuentes a una sobre vídeo sin cambiar de página.
• Búsqueda centrada en la extensión. La tarea real habitual es «tengo un archivo .xlsx, ¿qué pongo como Content-Type?»: escribir .xlsx aterriza directamente en application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.
• Tanto el nombre moderno como el heredado. Donde un tipo tiene una forma antigua que aún se ve en estado salvaje, se listan ambos con una nota, así que reconoces cualquiera de las dos direcciones de una cabecera HTTP.
• Tipos de fabricante incluidos. Microsoft Office, ZIP, gzip, 7z, RAR, WebAssembly, Web App Manifest, GraphQL: las formas largas application/vnd.* y application/*+json/application/*+xml están todas.
• Local e instantáneo. El conjunto de datos está incrustado en la página; cada búsqueda es un filtro del lado del cliente sin petición.

Ejemplo práctico#

JavaScript es la entrada más confusa, porque el tipo ha cambiado de nombre a lo largo de los años y los servidores siguen enviando ambos. Busca javascript y obtienes dos filas:

• text/javascript — js, mjs — «el tipo MIME estándar y moderno».
• application/javascript — js — «tipo MIME heredado (aún muy visto)».

La versión corta: text/javascript es lo que los estándares actuales de HTML y Fetch te dicen que uses, y lo que los servidores modernos emiten; application/javascript es el nombre antiguo de la RFC 4329 que seguirás viendo en cabeceras Content-Type y en documentación más vieja. Significan lo mismo y los navegadores los tratan de forma idéntica, pero para una configuración nueva de servidor prefiere text/javascript.

Unas cuantas consultas más que vale la pena memorizar, todas a una búsqueda:

• .json → application/json
• .svg → image/svg+xml (es una imagen, pero el sufijo +xml marca que está basado en XML)
• .woff2 → font/woff2 (fíjate en la categoría de nivel superior font/ dedicada, no application/)
• .wasm → application/wasm (binario WebAssembly: debe servirse exactamente así, sin charset, o no compilará)
• .pdf → application/pdf

Cuando un tipo es desconocido, los servidores vuelven a application/octet-stream, el tipo genérico de «esto son datos binarios, no asumas nada». Los navegadores suelen responder descargando el archivo en vez de intentar mostrarlo.

Preguntas frecuentes#

text/javascript o application/javascript: ¿cuál uso?#

Para código nuevo, envía text/javascript. Es lo que requieren las especificaciones actuales WHATWG HTML y Fetch, y lo que los navegadores realmente comprueban al decidir si ejecutan un <script>. application/javascript sigue funcionando en todas partes (es el estándar antiguo), pero es la forma heredada. Si estás configurando un servidor nuevo, una base de datos mime o una herramienta de build, usa por defecto text/javascript.

¿Por qué SVG lleva +xml en su tipo?#

El sufijo +xml es un sufijo de sintaxis estructurada: te dice que la serialización del tipo es XML por debajo. Así que image/svg+xml significa «una imagen, específicamente una descrita en XML». La misma convención aparece en application/ld+json (datos enlazados, serializados como JSON) y application/graphql+json. Las herramientas que entienden el sufijo pueden volver a un analizador XML o JSON genérico.

¿Para qué sirve application/octet-stream?#

Es el cajón de sastre para «datos binarios arbitrarios, tipo desconocido». Los servidores lo devuelven cuando no pueden identificar un archivo, y el comportamiento seguro del cliente es descargarlo en vez de intentar renderizarlo o ejecutarlo. Si alguna vez ves un archivo que esperabas abrir en el navegador empezar a descargar en su lugar, un Content-Type erróneo o ausente (que colapsa a octet-stream) es el culpable habitual.

¿Cómo fijo de verdad un Content-Type en mis archivos?#

Depende de dónde se sirva el archivo: un servidor de archivos estáticos lo lee de la extensión vía una base de datos mime; un framework web lo fija en código (a menudo response.setContentType(...) o una asignación de cabecera); un CDN lo expone en los metadatos de subida o de objeto. La llamada exacta difiere según el stack; lo único que debe estar bien es la cadena final en el cable, que es justamente lo que te da esta búsqueda.