Tipo MIME

Un tipo MIME (Multipurpose Internet Mail Extensions, ahora formalmente solo “tipo de medio” según RFC 6838) es un identificador de dos partes con el formato tipo/subtipo que indica al cliente qué tipo de datos tiene ante sí.

Ejemplos comunes:

• text/html — documento HTML
• application/json — datos JSON
• image/png, image/jpeg, image/webp — formatos de imagen
• application/pdf — documento PDF
• multipart/form-data — carga útil de subida de archivos
• application/octet-stream — binario opaco; el fallback “solo bytes, tú averigua qué es”

Las respuestas HTTP llevan los tipos MIME en la cabecera Content-Type. Los URI de datos (usados por nuestra herramienta de imagen a Base64) incrustan el tipo MIME directamente: data:image/png;base64,iVBOR.... Los navegadores usan el tipo MIME declarado para decidir cómo renderizar o descargar un recurso.

Nota histórica: MIME se definió originalmente para adjuntos de correo electrónico. El mismo registro ahora define los tipos de medios para la web, mensajería instantánea, RSS y la mayoría de los protocolos modernos.

El Registro de Tipos de Medios de IANA: cada tipo MIME legítimo está registrado en la Autoridad de Números Asignados de Internet. Los tipos de nivel superior son fijos (text, image, audio, video, application, multipart, message, model, font, example, además del prefijo heredado X-). Los subtipos se añaden mediante un proceso de registro IETF o de árbol de proveedor; application/vnd.openxmlformats-officedocument.wordprocessingml.document (el tipo MIME formal para .docx) es un ejemplo del árbol de proveedor. Los subtipos desconocidos pasan por defecto a application/octet-stream, lo que normalmente provoca un aviso de descarga del navegador en lugar de renderizado en línea.

La detección de MIME: el problema de seguridad: si un servidor devuelve el Content-Type incorrecto, los navegadores históricamente intentaban adivinar a partir de los primeros bytes de la respuesta. Esta “detección de contenido” permitía ataques entre sitios donde una imagen subida por el usuario podía reinterpretarse como HTML o JavaScript. La solución es X-Content-Type-Options: nosniff, que obliga al navegador a respetar el tipo declarado y rechazar la ejecución de contenido que no coincida. Los frameworks web modernos envían esta cabecera por defecto. Referencia: RFC 6838 — Media Type Specifications and Registration Procedures.

Parámetros: charset, boundary, profile

Un tipo MIME puede llevar parámetros después de un punto y coma. El más común es charset: Content-Type: text/html; charset=utf-8 indica al navegador que la respuesta es HTML codificado en UTF-8. Sin él, los navegadores recurren a codificaciones heredadas (Windows-1252 en muchos casos) que estropean el texto no ASCII. Para las subidas multipart/form-data, el parámetro boundary especifica el delimitador entre partes: multipart/form-data; boundary=---WebKitFormBoundary7MA4YWxkTrZu0gW. JSON-LD usa un parámetro profile: application/ld+json; profile="https://www.w3.org/ns/activitystreams". Los parámetros son insensibles a mayúsculas en los nombres; los valores son insensibles para la mayoría de los parámetros conocidos, pero sensibles para el boundary de multipart.

La convención de sufijo +

RFC 6839 añadió una convención de sufijo de sintaxis estructurada que permite a los nuevos tipos de medios declarar en qué formato genérico se analizan: application/atom+xml, application/vnd.api+json, image/svg+xml. El sufijo indica a un analizador genérico (una biblioteca XML o JSON) cómo leer los bytes, aunque no reconozca el tipo de proveedor específico. Los estándares web modernos dependen en gran medida de esto: cada tipo de medio de API basado en JSON termina en +json; cada uno basado en XML, en +xml. A partir de 2026, el registro IANA lista más de 2.300 tipos de medios registrados en todas las categorías de nivel superior, con el árbol application/ (más de 1.800 entradas) siendo con diferencia el más grande. Referencia: IANA Media Types Registry.