Referencia de Tipos MIME

Qué es realmente un tipo MIME

Un tipo MIME, también llamado tipo de medio, es una etiqueta corta que indica al software qué clase de datos contiene un archivo o el cuerpo de un mensaje. Nació en el correo electrónico (el nombre corresponde a Multipurpose Internet Mail Extensions), pero hoy aparece por todas partes en la web. El formato es siempre type/subtype: una categoría amplia, una barra y un formato específico. Así, text/html significa "texto, en forma HTML", image/png significa "una imagen, en forma PNG", y application/json significa "datos de aplicación, codificados como JSON".

El tipo de nivel superior procede de un conjunto fijo que mantiene la IANA, el registro oficial: text, image, audio, video, application, font, model, multipart, y algunos más nuevos como haptics. El subtipo es el formato específico. Los proveedores pueden añadir los suyos con un prefijo vnd. (por ejemplo application/vnd.ms-excel), y los tipos experimentales usaban históricamente un prefijo x-, aunque esa convención ahora se desaconseja.

Dónde importan los tipos MIME

El lugar más importante donde aparece un tipo MIME es la cabecera de respuesta HTTP Content-Type. Cuando un servidor envía una página, una imagen o una carga útil de API, esta cabecera indica al navegador cómo interpretar los bytes. Si la cabecera dice text/html, el navegador renderiza el marcado; si dice application/json, una llamada fetch() puede analizarlo; si dice application/pdf, se abre el visor integrado. La misma cabecera viaja también en el lado de la solicitud: cuando envías por POST un formulario o el cuerpo de una API, Content-Type indica al servidor cómo leer lo que enviaste.

Más allá de HTTP, los tipos MIME impulsan varios otros sistemas. Los clientes de correo los usan para decidir si un adjunto es una imagen que previsualizar o un binario que guardar. Los gestores de carga de archivos inspeccionan el tipo declarado para aceptar o rechazar archivos. Y el sistema operativo o el navegador usa el tipo, no solo la extensión del archivo, para elegir una aplicación predeterminada. La misma idea sustenta cómo los servidores informan de resultados y errores junto con los códigos de estado HTTP — una respuesta 200 con el tipo equivocado puede estar tan rota como un 404.

Los que usarás cada día

Un puñado de tipos cubre la gran mayoría del tráfico real:

• text/html — páginas web (extensión .html)
• text/css — hojas de estilo (.css)
• text/javascript — el tipo recomendado para JavaScript (.js, .mjs)
• application/json — el único tipo oficial de JSON, definido en RFC 8259 (.json)
• image/png, image/jpeg, image/webp, image/svg+xml — formatos de imagen comunes
• application/pdf — documentos PDF (.pdf)
• application/octet-stream — el comodín para datos binarios desconocidos o arbitrarios
• text/plain — el predeterminado para texto sin formato que no tiene un tipo más rico

JSON merece una nota porque hace tropezar a la gente. El único tipo correcto es application/json. El código antiguo a veces usaba text/json, text/plain o application/x-javascript, pero esos están obsoletos y algunos clientes se negarán a analizarlos. Tampoco hay un parámetro charset para JSON — la especificación obliga a usar UTF-8, así que escribir application/json; charset=utf-8 es redundante aunque inofensivo. Para una tabla más completa de formatos y extensiones, consulta nuestras tablas de referencia.

Por qué un Content-Type equivocado rompe las cosas

Los navegadores y los clientes confían en el tipo declarado, así que equivocarse tiene consecuencias concretas. Sirve una respuesta de API JSON como text/html y el navegador puede intentar renderizarla, o un cliente estricto puede lanzar un error de análisis antes de que tu código llegue a ejecutarse. Sirve un archivo CSS o JavaScript con el tipo equivocado y una función de seguridad llamada X-Content-Type-Options: nosniff hará que el navegador se niegue a aplicarlo, rompiendo silenciosamente el estilo o los scripts de tu página.

Las descargas son el otro fallo clásico. Si quieres que un archivo se descargue en lugar de mostrarse, el tipo importa junto con la cabecera Content-Disposition. Un PDF enviado como application/octet-stream se descarga como un archivo genérico en lugar de abrirse en el visor; una imagen enviada como text/plain aparece como caracteres ininteligibles. En el lado de la carga, un archivo mal etiquetado puede colarse ante una comprobación ingenua de la extensión, razón por la cual los validadores robustos inspeccionan los bytes reales (el "número mágico") en lugar de confiar en el tipo proporcionado por el cliente.

Históricamente, los navegadores intentaban adivinar, o "olfatear" (sniff), el tipo real cuando la cabecera parecía equivocada. Ese comportamiento causaba agujeros de seguridad, así que la mejor práctica moderna es enviar siempre un Content-Type preciso y desactivar el sniffing con nosniff. En resumen: establece el tipo de forma deliberada en cada respuesta y la mayoría de los errores de renderizado, descarga y análisis desaparecen.

Preguntas frecuentes