También disponible en: English · Português · Français · العربية
Tipos MIME
Los tipos de medios que de verdad te pueden servir, con los registrados marcados y las discrepancias resueltas.
Qué es un tipo MIME
Un tipo MIME —el estándar ya lo llama tipo de medio— es la etiqueta que un servidor pega a un archivo para que el navegador sepa qué es. Viaja en la cabecera Content-Type, tiene la forma text/html o image/png, y es lo que decide si tu navegador dibuja una página, muestra una imagen o te ofrece una descarga. Si está mal, un archivo perfectamente bueno llega como galimatías o como una descarga inesperada.
La lista con autoridad es el registro de tipos de medios de IANA, que contiene 2.318 repartidos en nueve árboles de primer nivel. Esta página se construye a partir de ese registro, del mime.types de Apache httpd y del de nginx, los tres descargados y no recordados.
Y deliberadamente no es un volcado del registro, por un motivo que conviene conocer antes de ir a buscarlo por tu cuenta.
Cómo usar esta lista
- Busca por extensión o por tipo. Una extensión coincide de forma exacta, con punto o sin él, así que webp y .webp funcionan igual. Cualquier otra cosa se busca dentro del tipo: image/ te da el árbol de imágenes y +xml los tipos con sufijo estructurado.
- Mira la etiqueta antes de fiarte de un tipo. Registrado significa que está en el registro de IANA, y la referencia que lo acompaña es el RFC o la organización que lo puso ahí. El resto son tipos que un servidor web te enviará tan tranquilo y que ningún registro ha visto jamás.
- Lee la tabla de discrepancias si tu archivo es de los conflictivos. Trece extensiones reciben respuestas distintas de Apache y de nginx, y la tabla dice a qué lado da la razón el registro en cada caso.
El registro no puede responder a la pregunta con la que llegas
Casi todo el mundo llega a una lista de tipos MIME con la misma duda: ¿qué Content-Type mando para un archivo .webp? El registro de IANA no te lo puede decir. Sus columnas son Nombre, Plantilla y Referencia: no hay ninguna columna de extensiones, porque qué extensión corresponde a qué tipo no es algo que IANA registre. Puedes buscar image/webp y confirmar que existe; lo que no puedes es buscar .webp.
Y no hay nada más que llene el hueco. El estándar de MIME Sniffing del WHATWG, que es el que los navegadores implementan de verdad, dice sin rodeos que las extensiones no se usan para determinar el tipo de un recurso obtenido por HTTP porque no son fiables y se falsifican con facilidad, y no publica ninguna tabla de extensiones propia. La correspondencia sencillamente no está normalizada en ninguna parte.
Lo que decide en la práctica es el servidor web que tengas delante de los archivos. Por eso esta lista usa una regla declarada en vez de una selección a mano: contiene todo tipo de medio al que Apache httpd o nginx asocian al menos una extensión, 790 en total, que es el conjunto que de verdad te pueden servir. El total del registro se imprime al lado para que nadie confunda la parte con el todo.
Dos servidores, 91 extensiones compartidas, 13 discrepancias
Apache asocia 998 extensiones y nginx 110. Noventa y una aparecen en ambos, y en trece de ellas —el 14,3 %— cada uno da una respuesta distinta. No son formatos raros: entre ellas están .js y .xml, dos de los tipos de archivo más servidos de la web.
Un simple recuento de discrepancias no valdría nada, así que en esta página cada conflicto se resuelve contra el registro. Tres los gana Apache sin discusión: en .bmp, .m4a y .pdb Apache da un tipo registrado y nginx uno que no lo está. Seis son nginx recurriendo a application/octet-stream, que está registrado y es técnicamente correcto y no le dice nada al navegador: es lo que hace que .exe, .iso y .deb se descarguen en vez de comportarse raro. En dos no hay tipo registrado por ninguno de los dos lados.
Los dos restantes son los interesantes, y lo son en direcciones opuestas. En .xml tanto application/xml como text/xml están registrados, y el RFC 7303 registra los dos a propósito: ningún servidor se equivoca y no hay respuesta que encontrar. En .js también están los dos registrados, pero la entrada de application/javascript cita el RFC 9239, el documento que convirtió text/javascript en la forma estándar y dejó obsoletas las demás. Apache está al día; nginx se ha quedado atrás. Mismo síntoma en la superficie, explicación completamente distinta, y solo leyendo las referencias se distinguen.
Un tercio de lo que te pueden servir no está en el registro
De los 790 tipos de medios que estos servidores asocian a extensiones, 547 están en el registro de IANA y 243 no. Eso es cerca de un tercio de todo lo que una instalación por defecto le entrega a un navegador, con un Content-Type que ningún organismo de normalización ha registrado nunca. La mayoría son los restos con prefijo x- de formatos que nunca llegaron a registrarse, y funcionan bien en la práctica precisamente porque nadie lo comprueba.
Siete van aún más lejos y usan un árbol de primer nivel que no existe. IANA registra nueve —application, audio, font, image, message, model, multipart, text y video— y Apache incluye seis tipos chemical/* para formatos de archivos moleculares y uno bajo x-conference. Un servidor web recién instalado te servirá un Content-Type cuyo primer componente ni siquiera es un árbol registrado.
Nada de esto es un escándalo: es cómo acaba funcionando una convención de treinta años sin mecanismo de control. Pero conviene saberlo antes de dar por hecho que un tipo que aparece en un fichero de configuración es estándar.
Límites honestos
Esto es una instantánea de tres documentos que se mueven, y la fecha en que se construyó está impresa abajo. El registro gana entradas con regularidad y los dos servidores actualizan sus correspondencias; el script que lo ensambla todo está en el repositorio, así que la página puede decir cuándo fue cierta.
Dos servidores tampoco son todos los servidores. IIS, Caddy, los frameworks de Node, las CDN y la biblioteca estándar de cada lenguaje llevan su propia tabla, y tampoco coincidirán con estas dos en todos los casos. Se eligieron Apache y nginx porque son los dos que sirven la mayor parte de la web, no porque sean las únicas opiniones que existen.
Y el límite de fondo es el que advierte el estándar de sniffing: el tipo que declara un servidor no es prueba de lo que contiene un archivo. Cualquiera puede subir un fichero llamado foto.png lleno de HTML, y justo por eso los navegadores husmean el contenido y por eso nunca debes fiarte de una cabecera Content-Type para una decisión de seguridad.
¿Por qué es gratis?
Porque es una lista de hechos públicos montada a partir de tres fuentes públicas. La página es texto estático con un buscador que la filtra en tu navegador: no se sube nada, no se guarda nada y no hay servidor de por medio para leerla.
Así que no hay cuenta, ni registro, ni nada reservado. El registro es un documento público, los dos ficheros mime.types son código abierto, y el script que los convierte en esta página está en el repositorio junto a ella.