MIME-typen naslagwerk

Wat een MIME-type eigenlijk is

Een MIME-type, ook wel mediatype genoemd, is een kort label dat software vertelt wat voor soort gegevens een bestand of berichttekst bevat. Het is ontstaan in e-mail (de naam staat voor Multipurpose Internet Mail Extensions), maar tegenwoordig duikt het overal op het web op. De opmaak is altijd type/subtype: een brede categorie, een slash en een specifiek formaat. Zo betekent text/html "tekst, in HTML-vorm", image/png betekent "een afbeelding, in PNG-vorm" en application/json betekent "applicatiedata, gecodeerd als JSON".

Het bovenste type komt uit een vaste verzameling die door IANA, het officiële register, wordt beheerd: text, image, audio, video, application, font, model, multipart en enkele nieuwere zoals haptics. Het subtype is het specifieke formaat. Leveranciers kunnen hun eigen toevoegen met een vnd.-prefix (bijvoorbeeld application/vnd.ms-excel), en experimentele typen gebruikten historisch een x--prefix, hoewel die conventie nu wordt afgeraden.

Waar MIME-typen van belang zijn

De belangrijkste plek waar een MIME-type verschijnt, is de HTTP-responsheader Content-Type. Wanneer een server een pagina, een afbeelding of een API-payload verstuurt, vertelt deze header de browser hoe de bytes geïnterpreteerd moeten worden. Als de header text/html zegt, rendert de browser opmaak; als hij application/json zegt, kan een fetch()-aanroep hem parseren; als hij application/pdf zegt, opent de ingebouwde viewer. Dezelfde header reist ook mee aan de verzoekzijde: wanneer je een formulier of een API-body POST't, vertelt Content-Type de server hoe hij moet lezen wat je hebt gestuurd.

Buiten HTTP sturen MIME-typen ook andere systemen aan. E-mailclients gebruiken ze om te beslissen of een bijlage een afbeelding is om voor te vertonen of een binair bestand om op te slaan. Bestandsuploadhandlers controleren het opgegeven type om bestanden te accepteren of te weigeren. En het besturingssysteem of de browser gebruikt het type, niet alleen de bestandsextensie, om een standaardapplicatie te kiezen. Hetzelfde idee ligt ten grondslag aan de manier waarop servers resultaten en fouten rapporteren naast HTTP-statuscodes — een 200-respons met het verkeerde type kan net zo kapot zijn als een 404.

De typen die je dagelijks gebruikt

Een handvol typen dekt de overgrote meerderheid van het echte verkeer:

• text/html — webpagina's (extensie .html)
• text/css — stijlbladen (.css)
• text/javascript — het aanbevolen type voor JavaScript (.js, .mjs)
• application/json — het enige officiële JSON-type, gedefinieerd in RFC 8259 (.json)
• image/png, image/jpeg, image/webp, image/svg+xml — veelgebruikte afbeeldingsformaten
• application/pdf — PDF-documenten (.pdf)
• application/octet-stream — de vangnet-aanduiding voor onbekende of willekeurige binaire data
• text/plain — de standaard voor platte tekst zonder rijker type

JSON verdient een kanttekening omdat het mensen in verwarring brengt. Het enige correcte type is application/json. Oudere code gebruikte soms text/json, text/plain of application/x-javascript, maar die zijn verouderd en sommige clients weigeren ze te parseren. Er is ook geen charset-parameter voor JSON — de specificatie schrijft UTF-8 voor, dus application/json; charset=utf-8 schrijven is overbodig, maar niet schadelijk. Voor een uitgebreidere tabel met formaten en extensies, zie onze referentietabellen.

Waarom een verkeerde Content-Type dingen kapotmaakt

Browsers en clients vertrouwen op het opgegeven type, dus een fout daarin heeft concrete gevolgen. Stuur een JSON API-respons als text/html en de browser probeert hem mogelijk te renderen, of een strikte client geeft een parseerfout voordat je code überhaupt wordt uitgevoerd. Stuur een CSS- of JavaScript-bestand met het verkeerde type en een beveiligingsfunctie genaamd X-Content-Type-Options: nosniff zorgt ervoor dat de browser weigert het toe te passen, waardoor de opmaak of scripts van je pagina stilletjes kapotgaan.

Downloads zijn het andere klassieke probleem. Als je wilt dat een bestand wordt gedownload in plaats van weergegeven, is het type belangrijk naast de Content-Disposition-header. Een PDF verstuurd als application/octet-stream wordt gedownload als een generiek bestand in plaats van dat hij wordt geopend in de viewer; een afbeelding verstuurd als text/plain verschijnt als wartaal. Aan de uploadkant kan een verkeerd gelabeld bestand een naieve extensiecontrole passeren, daarom inspecteren robuuste validators de werkelijke bytes (het "magic number") in plaats van te vertrouwen op het door de client opgegeven type.

Historisch gezien probeerden browsers het werkelijke type te raden, of te "sniffelen", wanneer de header er verkeerd uitzag. Dat gedrag veroorzaakte beveiligingsproblemen, dus de moderne beste werkwijze is altijd een nauwkeurige Content-Type te sturen en sniffelen uit te schakelen met nosniff. Kort samengevat: stel het type bewust in op elke respons en de meeste render-, download- en parseerproblemen verdwijnen.

Veelgestelde vragen