Types de média (types MIME)
Un type de média (anciennement appelé Multipurpose Internet Mail Extensions ou type MIME) indique la nature et le format d'un document, d'un fichier ou d'un ensemble d'octets. Les types MIME sont définis et normalisés dans l'RFC 6838 de l'IETF.
L'Internet Assigned Numbers Authority (IANA) (angl.) est responsable de tous les types MIME officiels. La liste la plus à jour et la plus complète se trouve sur la page Media Types (angl.).
Attention :
Les navigateurs utilisent le type MIME, et non l'extension de fichier, pour déterminer comment traiter une URL, il est donc important que les serveurs web envoient le bon type MIME dans l'en‑tête Content-Type
de la réponse. Si ce n'est pas correctement configuré, les navigateurs risquent d'interpréter de travers le contenu des fichiers, les sites peuvent mal fonctionner et les fichiers téléchargés peuvent être mal gérés.
Structure d'un type MIME
Un type MIME se compose le plus souvent de deux parties : un type et un sous‑type, séparés par une barre oblique (/
) — sans espace :
type/sous-type
Le type représente la catégorie générale dans laquelle le type de données s'inscrit, comme video
ou text
.
Le sous‑type identifie le type exact de données du type spécifié que représente le type MIME. Par exemple, pour le type MIME text
, le sous‑type peut être plain
(texte brut), html
(code source HTML) ou calendar
(pour les fichiers iCalendar/.ics
).
Chaque type possède son propre ensemble de sous‑types possibles. Un type MIME comporte toujours un type et un sous‑type, jamais l'un sans l'autre.
On peut ajouter un paramètre optionnel pour fournir des détails supplémentaires :
type/sous-type;paramètre=valeur
Par exemple, pour tout type MIME dont le type principal est text
, on peut ajouter le paramètre optionnel charset
pour préciser le jeu de caractères utilisé pour les données. Si aucun charset
n'est spécifié, la valeur par défaut est l'ASCII (US-ASCII
), sauf si elle est remplacée par les réglages de l'agent utilisateur. Pour indiquer un fichier texte en UTF‑8, on utilisera le type MIME text/plain;charset=UTF-8
.
Les types MIME ne sont pas sensibles à la casse mais sont traditionnellement écrits en minuscules. Les valeurs de paramètres, elles, peuvent être sensibles à la casse.
Types
Il existe deux grandes catégories de type : discrète et multipart. Les types discrets représentent un seul fichier ou support, comme un fichier texte ou audio unique, ou une seule vidéo. Un type multipart représente un document composé de plusieurs parties, chacune pouvant avoir son propre type MIME ; un type multipart peut aussi encapsuler plusieurs fichiers envoyés ensemble dans une même transaction. Par exemple, les types multipart sont utilisés lors de l'envoi de plusieurs pièces jointes dans un courriel.
Types discrets
Les types discrets actuellement enregistrés auprès de l'IANA sont :
application
-
Toute donnée binaire ne relevant pas explicitement d'un autre type ; soit des données qui seront exécutées ou interprétées d'une certaine manière, soit des données binaires nécessitant une application spécifique (ou une catégorie d'applications) pour être utilisées. Les données binaires génériques (ou dont le vrai type est inconnu) utilisent
application/octet-stream
. Autres exemples courants :application/pdf
,application/pkcs8
,application/zip
. (Voir le registre des types « application » auprès de l'IANA) audio
-
Données audio ou musicales. Exemples :
audio/mpeg
,audio/vorbis
. (Voir le registre des types « audio » auprès de l'IANA) example
-
Réservé à un rôle d'espace réservé dans les exemples montrant l'utilisation des types MIME. À ne jamais utiliser en dehors des extraits de code et de la documentation.
example
peut aussi être utilisé comme sous‑type ; par exemple, dans un exemple relatif à l'audio sur le Web, le type MIMEaudio/example
peut indiquer que le type est un espace réservé à remplacer par un type approprié dans un usage réel. font
-
Données de police/graphisme de caractères. Exemples courants :
font/woff
,font/ttf
,font/otf
. (Voir le registre des types « font » auprès de l'IANA) image
-
Données d'image ou graphiques, y compris images matricielles et vectorielles statiques, ainsi que des variantes animées comme les GIF animés ou l'APNG. Exemples courants :
image/jpeg
,image/png
,image/svg+xml
. (Voir le registre des types « image » auprès de l'IANA) model
-
Données de modèle pour un objet ou une scène 3D. Exemples :
model/3mf
,model/vrml
. (Voir le registre des types « model » auprès de l'IANA) text
-
Données purement textuelles, y compris tout contenu lisible par un·e humain·e, du code source, ou des données textuelles comme des valeurs séparées par des virgules (CSV). Exemples :
text/plain
,text/csv
,text/html
. (Voir le registre des types « text » auprès de l'IANA) video
-
Données ou fichiers vidéo, comme des films MP4 (
video/mp4
). (Voir le registre des types « video » auprès de l'IANA)
Pour des documents texte sans sous‑type spécifique, utilisez text/plain
. De même, pour des documents binaires sans sous‑type spécifique ou connu, utilisez application/octet-stream
.
Types multipart
Les types multipart indiquent une catégorie de document découpé en éléments, souvent de types MIME différents ; ils peuvent aussi servir — notamment en contexte de messagerie — à représenter plusieurs fichiers distincts faisant tous partie d'une même transaction. Ils représentent un document composite.
À l'exception de multipart/form-data
, utilisé avec la méthode POST
des formulaires HTML, et de multipart/byteranges
, utilisé avec le code 206
« Partial Content » pour envoyer une partie d'un document, HTTP ne gère pas les documents multipart de façon spéciale : le message est transmis au navigateur (qui affichera probablement une fenêtre « Enregistrer sous » s'il ne sait pas l'afficher).
Il existe deux types multipart :
message
-
Un message qui encapsule d'autres messages. Cela peut servir, par exemple, à représenter un courriel incluant un message transféré dans ses données, ou à permettre l'envoi de très grands messages en plusieurs morceaux comme s'il s'agissait de multiples messages. Exemples :
message/rfc822
(pour le transfert ou la citation d'un message lors d'une réponse) etmessage/partial
pour découper automatiquement un grand message en plus petits, à réassembler côté destinataire. (Voir le registre des types « message » auprès de l'IANA) multipart
-
Données composées de plusieurs éléments, pouvant chacun avoir des types MIME différents. Exemples :
multipart/form-data
(pour des données produites avec l'APIFormData
) etmultipart/byteranges
(défini dans l'RFC 7233, section 5.4.1 et utilisé avec le HTTP206
« Partial Content » lorsque la ressource renvoyée ne contient qu'une partie du contenu, par exemple via l'en‑têteRange
). (Voir le registre des types « multipart » auprès de l'IANA)
Types MIME importants pour les développeur·euse·s Web
>application/octet-stream
C'est la valeur par défaut pour les fichiers binaires. Comme cela signifie « binaire inconnu », les navigateurs ne l'exécutent généralement pas et n'essaient même pas de l'exécuter. Ils le traitent comme si l'en‑tête Content-Disposition
était positionné sur attachment
et proposent une boîte de dialogue « Enregistrer sous ».
text/plain
C'est la valeur par défaut pour les fichiers textuels. Même si cela signifie « texte inconnu », les navigateurs supposent qu'ils peuvent l'afficher.
Note :
text/plain
ne signifie pas « n'importe quelle donnée textuelle ». Si un navigateur attend un type de texte précis, il ne le considérera pas comme correspondant. En particulier, s'il télécharge un fichier text/plain
depuis un élément <link>
déclarant un fichier CSS, il ne le reconnaîtra pas comme une feuille de style valide si le type est text/plain
. Le type CSS text/css
doit être utilisé.
text/css
Les fichiers CSS utilisés pour styliser une page Web doivent être servis avec text/css
. Si un serveur ne reconnaît pas l'extension .css
, il peut les envoyer avec des types MIME text/plain
ou application/octet-stream
. Dans ce cas, la plupart des navigateurs ne les reconnaîtront pas comme du CSS et les ignoreront.
text/html
Tout contenu HTML doit être servi avec ce type. Les types MIME alternatifs pour XHTML (comme application/xhtml+xml
) sont aujourd'hui largement inutiles.
Note :
Utilisez application/xml
ou application/xhtml+xml
si vous voulez les règles d'analyse strictes d'XML, les sections <![CDATA[…]]>
ou des éléments hors des espaces de noms HTML/SVG/MathML.
text/javascript
Le contenu JavaScript doit toujours être servi avec le type MIME text/javascript
. Pour des raisons historiques, les navigateurs peuvent prendre en charge certains anciens types JavaScript listés ci‑dessous, mais vous ne devez pas supposer que des scripts servis avec un type autre que text/javascript
se chargeront ou s'exécuteront toujours.
Notez qu'en HTML, l'attribut type
des éléments <script>
ne peut contenir que l'essence du type MIME JavaScript : text/javascript
. Inclure un paramètre quelconque, comme charset=utf-8
, revient à définir un type MIME différent : le contenu du script est alors traité comme un bloc de données et n'est pas exécuté comme du JavaScript. (Définir type
sur un type MIME JavaScript est en soi une fonctionnalité dépréciée : vous devriez omettre type
dans ce cas.) À l'inverse, avec l'en‑tête HTTP Content-Type
, vous pouvez optionnellement préciser le paramètre charset
comme d'habitude.
Pour plus d'informations, voir : registre IANA des types « text » (angl.), RFC 9239 (angl.), et la spécification HTML (angl.).
Anciens types MIME pour JavaScript
En plus de text/javascript
, pour des raisons historiques, le standard MIME Sniffing (qui définit comment les navigateurs interprètent les types MIME et gèrent le contenu sans type valide) permet aussi de servir JavaScript avec l'un des types suivants :
application/javascript
Obsolèteapplication/ecmascript
Obsolèteapplication/x-ecmascript
Non standardapplication/x-javascript
Non standardtext/ecmascript
Obsolètetext/javascript1.0
Non standardtext/javascript1.1
Non standardtext/javascript1.2
Non standardtext/javascript1.3
Non standardtext/javascript1.4
Non standardtext/javascript1.5
Non standardtext/jscript
Non standardtext/livescript
Non standardtext/x-ecmascript
Non standardtext/x-javascript
Non standard
Note :
Même si un agent utilisateur donné peut en accepter un ou plusieurs, vous ne devez utiliser que text/javascript
. C'est le seul type MIME garanti de fonctionner maintenant et à l'avenir.
application/json
La JavaScript Object Notation (JSON) est un format textuel standard pour représenter des données structurées, fondé sur la syntaxe des objets JavaScript. Il est couramment utilisé pour transmettre des données dans les applications web.
Types d'images
Les fichiers dont le type MIME est image
contiennent des données d'image. Le sous‑type indique précisément quel format d'image est représenté.
Les types d'image suivants sont d'usage courant et considérés comme sûrs pour une utilisation sur les pages web :
image/apng
: APNG (Animated Portable Network Graphics)image/avif
: AVIF (AV1 Image File Format)image/gif
: GIF (Graphics Interchange Format)image/jpeg
: JPEG (Joint Photographic Experts Group)image/png
: PNG (Portable Network Graphics)image/svg+xml
: SVG (Scalable Vector Graphics)image/webp
: WebP
Le guide sur les types et formats d'images fournit des informations et des recommandations sur le choix du format selon les cas.
Types audio et vidéo
Comme pour les images, HTML n'impose pas aux navigateurs de prendre en charge des types de fichiers ou codecs spécifiques pour les éléments <audio>
et <video>
. Il est donc important, lors du choix des types et codecs, de considérer votre public cible et l'éventail de navigateurs (et leurs versions) qu'il peut utiliser.
Notre guide des formats de conteneur multimédia liste les types de fichiers couramment pris en charge par les navigateurs web, avec leurs cas d'usage, leurs limites, et des informations de compatibilité, entre autres détails.
Les guides sur les codecs audio et codecs vidéo récapitulent les codecs fréquemment pris en charge par les navigateurs, avec des détails de compatibilité et des informations techniques comme le nombre de canaux audio, le type de compression et les débits adaptés. Le guide sur les codecs utilisés par WebRTC va plus loin en couvrant spécifiquement les codecs pris en charge par les principaux navigateurs, afin d'aider au choix selon la couverture souhaitée.
Pour les types MIME des fichiers audio ou vidéo, on indique généralement le format de conteneur (type de fichier). Le paramètre codecs
optionnel peut être ajouté au type MIME pour préciser les codecs et les options d'encodage utilisées (profil, niveau, etc.).
Pour plus d'informations sur des types courants, voir la page Types MIME courants.
multipart/form-data
Le type multipart/form-data
peut être utilisé lorsqu'on envoie au serveur les valeurs d'un formulaire HTML rempli depuis le navigateur.
En tant que format de document multipart, il se compose de différentes parties, délimitées par une frontière (boundary, une chaîne commençant par deux tirets --
). Chaque partie est une entité avec ses propres en‑têtes HTTP, Content-Disposition
et Content-Type
pour les champs de téléversement de fichier.
Content-Type: multipart/form-data; boundary=aChaineDeDélimitation
(en-têtes divers associés à l'ensemble du document)
--aChaineDeDélimitation
Content-Disposition: form-data; name="monFichier"; filename="img.jpg"
Content-Type: image/jpeg
(données)
--aChaineDeDélimitation
Content-Disposition: form-data; name="monChamp"
(données)
--aChaineDeDélimitation
(éléments additionnels)
--aChaineDeDélimitation--
Le <form>
suivant :
<form
action="http://localhost:8000/"
method="post"
enctype="multipart/form-data">
<label>Nom : <input name="monChampTexte" value="Test" /></label>
<label><input type="checkbox" name="maCheckBox" /> Check</label>
<label>
Charger un fichier :
<input type="file" name="monFichier" value="test.txt" />
</label>
<button>Envoyer le fichier</button>
</form>
enverra le message :
POST / HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498
Content-Length: 465
-----------------------------8721656041911415653955004498
Content-Disposition: form-data; name="monChampTexte"
Test
-----------------------------8721656041911415653955004498
Content-Disposition: form-data; name="maCheckBox"
sur
-----------------------------8721656041911415653955004498
Content-Disposition: form-data; name="monFichier"; filename="test.txt"
Content-Type: text/plain
un fichier simple.
-----------------------------8721656041911415653955004498--
multipart/byteranges
Le type MIME multipart/byteranges
est utilisé pour envoyer des réponses partielles au navigateur.
Lorsque le code d'état 206 Partial Content
est renvoyé, ce type MIME indique que le document est composé de plusieurs parties, une par plage demandée. Comme pour les autres types multipart, l'en‑tête Content-Type
utilise une boundary
pour séparer les morceaux. Chaque morceau possède un en‑tête Content-Type
avec son type réel et un Content-Range
indiquant la plage représentée.
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
Content-Length: 385
--3d6b6a416f9b5
Content-Type: text/html
Content-Range: bytes 100-200/1270
eta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta name="vieport" content
--3d6b6a416f9b5
Content-Type: text/html
Content-Range: bytes 300-400/1270
-color: #f0f0f2;
margin: 0;
padding: 0;
font-family: "Open Sans", "Helvetica
--3d6b6a416f9b5--
Importance de définir le bon type MIME
Certaines configurations serveur peuvent utiliser le type MIME associé pour effectuer des optimisations, comme la concaténation de fichiers, la compression ou la mise en cache. Voir h5bp/server-configs-apache (angl.) pour un exemple de configuration Apache qui compresse certains types MIME.
La plupart des serveurs web envoient les ressources non reconnues avec le type application/octet-stream
. Pour des raisons de sécurité, la plupart des navigateurs n'autorisent pas de définir une action par défaut personnalisée (comme « Ouvrir dans Word ») pour ces ressources, forçant l'utilisateur·ice à enregistrer le fichier pour l'ouvrir.
Quelques erreurs de configuration fréquentes côté serveur :
- Fichiers compressés RAR. L'idéal serait d'indiquer le type réel des fichiers d'origine ; souvent impossible car un fichier .RAR peut contenir plusieurs ressources de types différents. Dans ce cas, configurez le serveur pour envoyer
application/x-rar-compressed
. - Audio et vidéo. Seules les ressources avec le bon type MIME seront lues dans les éléments
<video>
ou<audio>
. Veillez à spécifier le type de média correct pour l'audio et la vidéo. - Formats propriétaires. Un type spécifique comme
application/vnd.mspowerpoint
permet aux utilisateur·ice·s d'ouvrir automatiquement ces fichiers dans le logiciel de présentation de leur choix.
Détection du type MIME (MIME sniffing)
En l'absence de type MIME, ou dans certains cas où les navigateurs estiment qu'il est incorrect, ils peuvent réaliser une détection de type (MIME sniffing) — c'est‑à‑dire deviner le bon type en inspectant les octets de la ressource.
Chaque navigateur effectue cette détection différemment et dans des circonstances diverses. (Par exemple, Safari regarde l'extension de fichier dans l'URL si le type envoyé est inadapté.) Cela pose des problèmes de sécurité car certains types MIME représentent du contenu exécutable. Les serveurs peuvent empêcher la détection en envoyant l'en‑tête X-Content-Type-Options
.
Autres moyens d'indiquer le type de document
Les types MIME ne sont pas l'unique moyen de transmettre des informations de type de document :
- Les suffixes de nom de fichier sont parfois utilisés, notamment sous Microsoft Windows. Tous les systèmes d'exploitation ne les considèrent pas comme significatifs (par exemple Linux et macOS), et rien ne garantit qu'ils soient corrects.
- Les nombres magiques. La syntaxe de certains formats permet d'inférer le type de fichier en observant sa structure binaire. Par exemple, les fichiers GIF commencent par la valeur hexadécimale
47 49 46 38 39
(GIF89
), et les fichiers PNG par89 50 4E 47
(.PNG
). Tous les types de fichiers n'ont pas de nombre magique ; cette méthode n'est donc pas fiable à 100 % non plus.