Content-Type in webontwikkeling: wat is het, MIME-typen en hoe werkt het

Wat is Content-Type?

Content-Type — is een HTTP-header uit de groep representation headers die de ontvanger informeert over het formaat van gegevens in de berichtinhoud. Het is verplicht voor HTTP-verzoeken en -antwoorden die een body bevatten, en zonder kan de client de ontvangen bytes niet correct interpreteren. De browser of mobiele app kiest op basis van Content-Type de parser: voor text/html start het de HTML-engine, voor image/png — de PNG-decoder, voor application/json — de JSON-parser.

De waarde van Content-Type is een MIME-type — een gestandaardiseerde identificatie van het gegevensformaat. De afkorting MIME staat voor Multipurpose Internet Mail Extensions, omdat deze standaard oorspronkelijk is gemaakt voor e-mailbijlagen. Het is echter de basis van HTTP geworden en wordt tegenwoordig overal gebruikt — van het verzenden van webpagina's tot gegevensuitwisseling in REST API's. Elk MIME-type bestaat uit twee delen: een hoofdcategorie en een verfijnend subtype, gescheiden door een schuine streep.

De charset-parameter vult Content-Type aan voor tekstformaten. Bijvoorbeeld, Content-Type: text/html; charset=utf-8 betekent dat een HTML-document in UTF-8-codering wordt verzonden. Volgens IETF RFC 7231, sectie 3.1.1.5, is de Content-Type-header verplicht voor HTTP-berichten met een body, en het ontbreken ervan wordt geïnterpreteerd als application/octet-stream of leidt tot MIME sniffing.

Geschiedenis van MIME-typen in HTTP

Het HTTP/0.9-protocol, uitgebracht in 1991, verzond alleen HTML-pagina's, dus het gegevenstype was standaard bepaald. Met de komst van HTTP/1.0 in de RFC 1945-specificatie realiseerden ontwikkelaars de noodzaak om afbeeldingen, stijlbladen en scripts te verzenden. Ze pasten de MIME-standaard van het e-mailprotocol aan en Content-Type werd een integraal onderdeel van HTTP. Sindsdien is het IANA-register uitgebreid tot honderden waarden — van het bekende text/html tot moderne image/avif en application/manifest+json.

Rol van Content-Type in beveiliging

Content-Type speelt een cruciale rol bij bescherming tegen aanvallen. Als de server een HTML-bestand verzendt met het MIME-type text/plain, zal de browser geen JavaScript uitvoeren en geen DOM opbouwen — dit voorkomt XSS-aanvallen. De door OWASP aanbevolen header X-Content-Type-Options: nosniff verbiedt de browser volledig om het MIME-type te raden op basis van de inhoud. Volgens PortSwigger Research kwamen aanvallen met MIME sniffing vooral veel voor in Internet Explorer 6-9, waar de browser Content-Type negeerde en het type bepaalde op basis van de eerste bytes van het bestand.

Structuur van MIME-type

Het MIME-type wordt opgegeven in het formaat type/subtype, waarbij type de algemene gegevenscategorie is en subtype het specifieke formaat daarbinnen. Bijvoorbeeld, in de waarde image/png verwijst de categorie image naar een afbeelding en het subtype png naar het formaat Portable Network Graphics. Er zijn slechts enkele categorieën: text, image, audio, video, application, multipart en message. De rest van de diversiteit wordt verzorgd door subtypes, waarvan er honderden zijn.

Aanvullende parameters worden doorgegeven via een puntkomma na het subtype. De meest voorkomende parameter is charset voor het aangeven van de codering. Content-Type: application/json; charset=utf-8 geeft aan dat een JSON-document in UTF-8-codering wordt verzonden. Formeel is charset voor application/json overbodig, omdat JSON altijd in UTF-8 is volgens RFC 8259, maar expliciete vermelding verbetert de compatibiliteit met oudere HTTP-clients.

Standaard en niet-standaard MIME-typen

Standaard MIME-typen worden geregistreerd in het IANA-register en hebben een prefix van de hoofdcategorie. Niet-standaard (vendor-specific) typen gebruiken het prefix x- of het formaat vnd.company.type — bijvoorbeeld application/vnd.google-earth.kml+xml voor het KML-formaat van Google. Browsers kunnen niet-standaard typen mogelijk niet herkennen, daarom wordt voor onbekende bijlagen application/octet-stream gebruikt — een universele binaire stroom die de browser niet probeert weer te geven maar aanbiedt om als bestand te downloaden.

De charset-parameter in de praktijk

De charset-parameter is cruciaal voor de correcte weergave van tekst. Zonder deze parameter kan de browser tekens verkeerd interpreteren, wat leidt tot mojibake (vervormde tekens). Voor het web is de standaard UTF-8, maar ISO-8859-1 (Latin-1) voor West-Europese talen en windows-1251 voor Cyrillisch op oude sites komen ook voor. Aanbeveling van W3C — specificeer altijd charset=utf-8 voor text/html en text/plain, en voor application/json is charset niet vereist.

Belangrijkste Content-Type typen

In de praktijk werken webontwikkelaars en mobiele ontwikkelaars met een beperkte set MIME-typen. Kennis van deze typen is noodzakelijk voor de juiste serverconfiguratie, het schrijven van HTTP-clients en de verwerking van statische bestanden. text/html — het belangrijkste type voor webpagina's, standaard geretourneerd door Apache- en Nginx-servers voor HTML-bestanden. application/xhtml+xml wordt minder vaak gebruikt en alleen voor XHTML-documenten.

application/json is de standaard geworden voor REST API's. Servers retourneren JSON-gegevens met dit MIME-type en clients sturen het in POST- en PUT-verzoeken. text/javascript (verouderd) en application/javascript worden gebruikt voor JavaScript-bestanden. Volgens W3Techs Survey, 2025 is JSON het snelst groeiende gegevensformaat op het web en heeft het XML in 2018 ingehaald. Voor SOAP-services wordt nog steeds text/xml of application/soap+xml gebruikt.

Voor afbeeldingen wordt het MIME-type bepaald door het bestandsformaat: image/jpeg voor JPEG, image/png voor PNG, image/gif voor GIF, image/webp voor het moderne WebP-formaat. image/svg+xml wordt gebruikt voor vectorafbeeldingen en ondersteunt ingebedde stijlen en scripts. video/mp4, audio/mpeg en application/pdf — andere veelvoorkomende typen. Voor weblettertypen worden font/woff2, font/woff en font/ttf gebruikt.

Content-Type bij bestandsupload

Bij het verzenden van bestanden via een HTML-formulier wordt multipart/form-data gebruikt — een samengesteld MIME-type dat het verzoek in meerdere delen splitst. Elk deel heeft zijn eigen Content-Type- en Content-Disposition-header, die de veldnaam en de originele bestandsnaam aangeven. De server ontvangt het bestand met het werkelijke MIME-type, bepaald door de browser, en kan het aan de backendzijde controleren. application/octet-stream wordt toegepast voor bestanden van onbekend type — de browser probeert de inhoud niet weer te geven maar biedt aan om deze op te slaan.

Invloed van Content-Type op caching

Het MIME-type beïnvloedt het cachebeleid van CDN en browser. Afbeeldingen met stabiele URL's worden meestal langdurig gecachet (een jaar of langer), terwijl HTML-pagina's — voor minuten of seconden. CDN-servers Cloudflare en Akamai gebruiken Content-Type voor de keuze van het compressiealgoritme: text/* wordt gecomprimeerd met gzip of brotli, image/* — niet, omdat afbeeldingen al zijn gecomprimeerd. De juiste configuratie van Content-Type op de server heeft directe invloed op de laadprestaties van pagina's en mobiele applicaties.

Hoe server en client Content-Type gebruiken

De server stelt de Content-Type-header in het HTTP-antwoord in op basis van het type aangevraagd bestand of dynamisch gegenereerde inhoud. Populaire webservers Nginx en Apache hebben ingebouwde MIME-typetabellen die de bestandsextensie koppelen aan de juiste Content-Type. Bijvoorbeeld, het bestand index.html krijgt text/html en style.css — text/css. Voor dynamische antwoorden stelt de ontwikkelaar Content-Type in de applicatiecode in PHP, Python, Java of Kotlin.

De client gebruikt Content-Type voor de keuze van de handler. Als de server text/html retourneert, start de browser de HTML-parser en bouwt de DOM-boom. Als image/png — start de PNG-decoder. Als Content-Type ontbreekt of onjuist is, past de client MIME sniffing toe — probeert het type te raden op basis van de handtekening (magic bytes) aan het begin van het bestand. JPEG begint met bytes FF D8 FF, PNG — met 89 50 4E 47, en PDF — met 25 50 44 46. Dit proces is potentieel gevaarlijk en wordt uitgeschakeld door de header X-Content-Type-Options: nosniff.

In mobiele applicaties wordt Content-Type verwerkt door HTTP-clients. OkHttp op Android parseert automatisch de Content-Type-header uit het antwoord en biedt deze aan via de methode Response.header("Content-Type"). De iOS-client URLSession doet hetzelfde via de eigenschap URLResponse.mimeType. Op beide platforms wordt Content-Type gebruikt voor de keuze van de parser: JSON — via Moshi of Gson op Android, via Codable op iOS; afbeeldingen — via Glide, Coil of SDWebImage.

Content Negotiation via Accept en Content-Type

Content negotiation (inhoudsonderhandeling) — een HTTP-mechanisme waarbij de client het gewenste antwoordformaat aangeeft via de Accept-header, en de server het juiste formaat kiest en terugstuurt met de bijbehorende Content-Type. Bijvoorbeeld, de client stuurt Accept: application/json, de server antwoordt met Content-Type: application/json. Als de server het gevraagde formaat niet kan leveren, retourneert hij 406 Not Acceptable. In REST API's stelt dit mechanisme één endpoint in staat gegevens te retourneren in JSON, XML of HTML.

Content-Type in verzoeken en antwoorden

De Content-Type-header wordt zowel in HTTP-verzoeken (Request) als in HTTP-antwoorden (Response) gebruikt. In verzoeken geeft het het formaat van de verzoekinhoud aan, bijvoorbeeld bij het verzenden van JSON via POST. In antwoorden — het formaat van de geretourneerde gegevens. Het fundamentele verschil is dat de Content-Type van het verzoek door de client wordt ingesteld en die van het antwoord door de server. Onjuiste instelling van Content-Type in een verzoek zorgt ervoor dat de server de inhoud niet kan parsen, wat resulteert in een fout 400 Bad Request of 415 Unsupported Media Type.

In HTTP-verzoeken is Content-Type verplicht voor de methoden POST, PUT en PATCH als het verzoek een body bevat. GET, HEAD en DELETE gebruiken meestal geen body, dus Content-Type wordt voor hen niet gespecificeerd of genegeerd. Bij het verzenden van een HTML-formulier met het attribuut enctype="multipart/form-data" stelt de browser automatisch Content-Type: multipart/form-data in met een unieke grenstekenreeks (boundary) die de delen van het samengestelde verzoek scheidt. Elk deel wordt gescheiden door --boundary en het einde van het verzoek wordt gemarkeerd door --boundary--.

In HTTP-antwoorden wordt Content-Type door de server ingesteld. Als de server geen Content-Type specificeert, schakelt de client ofwel MIME sniffing in, of verwerkt het antwoord als application/octet-stream. De HTTP-methode HEAD maakt het mogelijk de antwoordheaders, inclusief Content-Type, te verkrijgen zonder de body te verzenden. Dit is handig om het type resource te controleren voordat deze volledig wordt geladen. CDN-servers kunnen Content-Type overschrijven bij transformatie van inhoud — bijvoorbeeld bij het converteren van afbeeldingen naar WebP.

import okhttp3.*

fun checkContentType() {
    val client = OkHttpClient()
    val request = Request.Builder()
        .url("https://api.example.com/resource")
        .head()
        .build()

    client.newCall(request).execute().use { response ->
        val contentType = response.header("Content-Type")
        val mediaType = MediaType.parse(contentType)
        println("Type: ${mediaType?.type}, Subtype: ${mediaType?.subtype}")
    }
}

Content-Type in mobiele HTTP-clients

In mobiele ontwikkeling wordt de Content-Type-header automatisch verwerkt door HTTP-clients. In OkHttp op Android wordt Content-Type ingesteld via RequestBody: val body = "{}".toRequestBody("application/json".toMediaType()). Retrofit beheert Content-Type via annotaties: @Body voor JSON, @Part voor multipart. Op iOS stelt URLSession Content-Type in voor HTTPBody, en Alamofire doet dit via de parameter encoding: JSONEncoding.default of URLEncoding.default. Handmatige instelling van Content-Type is vereist bij het werken met raw sockets of aangepaste protocollen.

Fouten bij het werken met Content-Type

Onjuiste Content-Type — een van de meest voorkomende problemen bij de ontwikkeling en integratie van webservices. De meest voorkomende fout is wanneer de server text/html retourneert in plaats van application/json. De client ontvangt JSON als een HTML-string, kan deze niet parsen en genereert een uitzondering. Dit gebeurt wanneer het webframework standaard is geconfigureerd voor HTML en de ontwikkelaar vergeet Content-Type te overschrijven voor het API-endpoint. In PHP uit zich dit door het ontbreken van header('Content-Type: application/json'), in Spring Boot — door het ontbreken van de annotatie produces.

De tweede meest voorkomende fout is onjuiste of ontbrekende charset. Als de server text/html; charset=iso-8859-1 verzendt en de browser verwacht UTF-8, worden Cyrillische tekens vervormd weergegeven. Dit probleem is kenmerkend voor oude sites die niet zijn overgestapt op UTF-8. Voor JSON komt een dergelijke fout minder vaak voor, omdat RFC 8259 UTF-8 voorschrijft zonder extra overeenstemming. Oplossing — specificeer altijd expliciet charset=utf-8 voor tekstuele MIME-typen in de serverconfiguratie.

Het derde probleem — discrepantie tussen Content-Type en werkelijke inhoud. Als de server Content-Type: image/png verzendt maar de antwoordbody een WebP-afbeelding bevat, kan de browser deze mogelijk niet decoderen. CDN-servers comprimeren soms afbeeldingen met wijziging van het formaat, maar werken de Content-Type-header niet bij. Controle van de overeenstemming van Content-Type met de werkelijke inhoud is een verplichte fase van API-testen en integratietesten van mobiele applicaties.

Diagnose en correctie van Content-Type-fouten

Gebruik voor debugging de ontwikkeltools van de browser (tabblad Network), curl met de vlag -I voor het controleren van antwoordheaders, of traffic sniffers zoals Charles Proxy en Wireshark. Nginx wordt geconfigureerd via de richtlijn include mime.types, Apache — via AddType en AddDefaultCharset. Controleer voor statische bestanden altijd of de bestandsextensie overeenkomt met het MIME-type. Voor dynamische antwoorden stelt u in alle programmeertalen expliciet Content-Type in voordat u gegevens uitvoert — dit voorkomt de overgrote meerderheid van problemen.