Référence MIME / Content-Type

Qu’est-ce qu’une référence des types MIME ?#

Un type MIME (aussi appelé type de média ou Content-Type) est le libellé court qui indique au récepteur quelle sorte d’octets contient un document : text/html est une page web, application/json est des données JSON, image/png est une image PNG. Le format est toujours type/sous-type — une catégorie large, une barre oblique, puis un nom spécifique. HTTP s’appuie sur ces libellés pour décider d’afficher, télécharger, analyser ou rejeter une réponse ; les navigateurs s’appuient dessus pour choisir le bon gestionnaire (un <img> attend un type d’image, un <script> attend un type JavaScript) ; l’e-mail s’appuie sur eux pour joindre des fichiers.

Le format a l’air simple, mais le paysage est véritablement déroutant. Il y a sept catégories de premier niveau (application, audio, font, image, model, text, video), de nombreux fichiers correspondent à plusieurs extensions (.jpg, .jpeg, .jpe sont tous image/jpeg), certains types ont une forme ancienne et une moderne (application/javascript contre text/javascript), et choisir le mauis provoque de vrais bugs — une feuille de style servie en text/plain ne s’appliquera pas, une police servie en application/octet-stream ne se chargera pas. Cette page est une recherche consultable pour toujours choisir le bon libellé.

Comment l’utiliser#

1. Recherchez par n’importe quoi. La zone de recherche filtre tout le tableau. Trois façons de requêter :
   • Saisissez une extension de fichier avec un point devant — .jpg, .woff2, .mp4 — et vous obtenez exactement les types mappés à cette extension.
   • Saisissez le type ou sous-type lui-même — image, json, svg — pour filtrer par nom.
   • Saisissez un mot — archive, font, spreadsheet — pour chercher dans les descriptions.
2. Lisez la ligne. Les colonnes sont Content-Type (le type/sous-type complet), Extensions (les suffixes de fichiers courants qui s’y mappent), Catégorie (l’un des sept groupes de premier niveau) et Description (une note d’une ligne sur l’usage du type).
3. Choisissez le bon. Pour une extension donnée, il y a généralement un type canonique ; là où deux existent (le cas JavaScript est le classique), la description explique lequel est courant.

Caractéristiques principales#

• Sept catégories, une seule table. Les types application, audio, font, image, model, text et video vivent tous ensemble, donc vous pouvez passer d’une question de police à une question de vidéo sans changer de page.
• Recherche d’abord par extension. La tâche réelle courante est « j’ai un fichier .xlsx, que dois-je mettre comme Content-Type ? » — saisir .xlsx atterrit directement sur application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.
• Les noms modernes et hérités. Là où un type a une ancienne forme encore vue dans la nature, les deux sont listés avec une note, donc vous reconnaissez l’un ou l’autre sens d’un en-tête HTTP.
• Types vendeur inclus. Microsoft Office, ZIP, gzip, 7z, RAR, WebAssembly, Web App Manifest, GraphQL — les longues formes application/vnd.* et application/*+json/application/*+xml sont toutes là.
• Local et instantané. Le jeu de données est embarqué dans la page ; chaque recherche est un filtre côté client sans requête.

Exemple commenté#

JavaScript est l’entrée la plus déroutante, parce que le type a changé de nom au fil des ans et que les serveurs envoient encore les deux. Cherchez javascript et vous obtenez deux lignes :

• text/javascript — js, mjs — « le type MIME standard et moderne. »
• application/javascript — js — « type MIME JavaScript hérité (encore largement vu). »

La version courte : text/javascript est ce que les standards HTML et Fetch actuels vous disent d’utiliser, et ce que les serveurs modernes émettent ; application/javascript est l’ancien nom de la RFC 4329 que vous verrez encore dans d’anciens en-têtes Content-Type et d’anciennes documentations. Ils signifient la même chose et les navigateurs les traitent à l’identique — mais pour une configuration de serveur neuve, préférez text/javascript.

Quelques autres recherches à mémoriser, toutes à une recherche près :

• .json → application/json
• .svg → image/svg+xml (c’est une image, mais le suffixe +xml signale qu’elle est basée sur XML)
• .woff2 → font/woff2 (notez la catégorie de premier niveau font/ dédiée, pas application/)
• .wasm → application/wasm (binaire WebAssembly — doit être servi exactement ainsi, sans charset, sinon il ne compile pas)
• .pdf → application/pdf

Quand un type est inconnu, les serveurs replient sur application/octet-stream — le type générique « ce sont des données binaires, ne supposez rien ». Les navigateurs répondent généralement en téléchargeant le fichier au lieu d’essayer de l’afficher.

FAQ#

text/javascript ou application/javascript — lequel utiliser ?#

Pour du code neuf, envoyez text/javascript. C’est ce qu’exigent les spécifications WHATWG HTML et Fetch actuelles, et ce que les navigateurs vérifient réellement pour décider d’exécuter un <script>. application/javascript fonctionne encore partout (c’est l’ancien standard), mais c’est la forme héritée. Si vous configurez un nouveau serveur, une base de données MIME ou un outil de build, par défaut sur text/javascript.

Pourquoi le SVG a-t-il +xml dans son type ?#

Le suffixe +xml est un suffixe de syntaxe structurée : il indique que la sérialisation du type est du XML en dessous. Donc image/svg+xml signifie « une image, plus précisément décrite en XML ». La même convention apparaît dans application/ld+json (données liées, sérialisées en JSON) et application/graphql+json. Les outils qui comprennent le suffixe peuvent se replier sur un analyseur XML ou JSON générique.

À quoi sert application/octet-stream ?#

C’est le fourre-tout pour « données binaires arbitraires, type inconnu ». Les serveurs le renvoient quand ils ne peuvent pas identifier un fichier, et le comportement sûr côté client est de le télécharger plutôt que d’essayer de l’afficher ou de l’exécuter. Si un fichier que vous espériez ouvrir dans le navigateur se met à télécharger, un Content-Type erroné ou manquant (réduit à octet-stream) en est le coupable habituel.

Comment concrètement définir un Content-Type sur mes fichiers ?#

Cela dépend de l’origine du fichier — un serveur de fichiers statiques le lit depuis l’extension via une base de données MIME, un framework web le définit dans le code (souvent response.setContentType(...) ou une affectation d’en-tête), et un CDN l’expose dans le téléversement ou les métadonnées de l’objet. L’appel exact diffère selon la stack ; la seule chose qui doit être juste est la chaîne finale sur le fil, ce que cette recherche vous donne exactement.