Content-Type i webbutveckling: vad är det, MIME-typer och hur det fungerar

Vad är Content-Type?

Content-Type — är en HTTP-rubrik från gruppen representation headers som informerar mottagaren om formatet på data i meddelandets brödtext. Den är obligatorisk för HTTP-begäranden och -svar som innehåller en brödtext (body), och utan den kan klienten inte tolka mottagna byte korrekt. Webbläsaren eller mobilapplikationen väljer parser baserat på Content-Type: för text/html startar HTML-motorn, för image/png — PNG-avkodaren, för application/json — JSON-parsern.

Värdet för Content-Type är en MIME-typ — en standardiserad identifierare för dataformat. Förkortningen MIME står för Multipurpose Internet Mail Extensions, eftersom denna standard ursprungligen skapades för e-postbilagor. Den har dock blivit grunden för HTTP och används idag överallt — från överföring av webbsidor till datautbyte i REST API. Varje MIME-typ består av två delar: en huvudkategori och en förtydligande undertyp, separerade med ett snedstreck.

Parametern charset kompletterar Content-Type för textbaserade format. Till exempel betyder Content-Type: text/html; charset=utf-8 att ett HTML-dokument i UTF-8-kodning överförs. Enligt IETF RFC 7231, avsnitt 3.1.1.5, är Content-Type-rubriken obligatorisk för HTTP-meddelanden som innehåller en brödtext, och dess frånvaro tolkas som application/octet-stream eller leder till MIME-sniffning.

Historik om MIME-typers uppkomst i HTTP

HTTP/0.9-protokollet, som släpptes 1991, överförde endast HTML-sidor, så datatypen var förutbestämd. Med tillkomsten av HTTP/1.0 i RFC 1945-specifikationen insåg utvecklare behovet av att överföra bilder, stilmallar och skript. De anpassade MIME-standarden från e-postprotokollet, och Content-Type blev en oskiljaktig del av HTTP. Sedan dess har IANA-registret expanderat till hundratals värden — från välkända text/html till moderna image/avif och application/manifest+json.

Content-Types roll i säkerhet

Content-Type spelar en kritisk roll i skyddet mot attacker. Om servern skickar en HTML-fil med MIME-typen text/plain, kommer webbläsaren inte att exekvera JavaScript och bygga DOM — detta förhindrar XSS-attacker. Rubriken X-Content-Type-Options: nosniff, som rekommenderas av OWASP, förbjuder helt webbläsaren att gissa MIME-typen baserat på innehållet. Enligt PortSwigger Research var attacker som använder MIME-sniffning särskilt utbredda i Internet Explorer 6-9, där webbläsaren ignorerade Content-Type och bestämde typen baserat på filens första byte.

Struktur för MIME-typ

MIME-typen anges i formatet type/subtype, där type är den allmänna datakategorin och subtype är det specifika formatet inom den. Till exempel, i värdet image/png hänvisar kategorin image till en bild och undertypen png — till formatet Portable Network Graphics. Det finns bara ett fåtal kategorier: text, image, audio, video, application, multipart och message. Resten av mångfalden tillhandahålls av undertyper, som finns i hundratals.

Ytterligare parametrar överförs via semikolon efter undertypen. Den vanligaste parametern är charset för att ange kodning. Content-Type: application/json; charset=utf-8 informerar om att ett JSON-dokument i UTF-8-kodning överförs. Formellt är charset för application/json överflödigt, eftersom JSON alltid är i UTF-8 enligt RFC 8259-specifikationen, men explicit angivande förbättrar kompatibiliteten med äldre HTTP-klienter.

Standard och icke-standard MIME-typer

Standard MIME-typer registreras i IANA-registret och har prefix för huvudkategori. Icke-standard (vendor-specific) typer använder prefixet x- eller formatet vnd.company.type — till exempel application/vnd.google-earth.kml+xml för KML-format från Google. Webbläsare kanske inte känner igen icke-standard typer, därför används application/octet-stream för okända bilagor — en universell binär ström som webbläsaren inte försöker visa utan erbjuder att ladda ner som fil.

Parametern charset i praktiken

Parametern charset är kritisk för korrekt visning av text. Utan den kan webbläsaren tolka tecken felaktigt, vilket leder till mojibake (förvanskade tecken). Standarden för webben är UTF-8, men ISO-8859-1 (Latin-1) för västeuropeiska språk och windows-1251 för kyrilliska på gamla webbplatser förekommer också. Rekommendation från W3C — ange alltid charset=utf-8 för text/html och text/plain, och för application/json krävs inte charset.

Huvudtyper av Content-Type

I praktiken arbetar webbutvecklare och mobilutvecklare med en begränsad uppsättning MIME-typer. Kunskap om dessa typer är nödvändig för korrekt serverkonfiguration, skrivning av HTTP-klienter och bearbetning av statiska filer. text/html — huvudtypen för webbsidor, som returneras som standard av Apache- och Nginx-servrar för HTML-filer. application/xhtml+xml används mer sällan och endast för XHTML-dokument.

application/json har blivit standard för REST API. Servrar returnerar JSON-data med denna MIME-typ och klienter skickar den i POST- och PUT-begäranden. text/javascript (föråldrad) och application/javascript används för JavaScript-filer. Enligt W3Techs Survey, 2025 är JSON det snabbast växande dataformatet på webben och passerade XML 2018. För SOAP-tjänster används fortfarande text/xml eller application/soap+xml.

För bilder bestäms MIME-typen av filformatet: image/jpeg för JPEG, image/png för PNG, image/gif för GIF, image/webp för moderna WebP-format. image/svg+xml används för vektorgrafik och stöder inbäddade stilar och skript. video/mp4, audio/mpeg och application/pdf — andra vanligt förekommande typer. För webbteckensnitt används font/woff2, font/woff och font/ttf.

Content-Type vid filuppladdning

Vid sändning av filer via ett HTML-formulär används multipart/form-data — en sammansatt MIME-typ som delar upp begäran i flera delar. Varje del har sin egen Content-Type- och Content-Disposition-rubrik, som anger fältnamnet och det ursprungliga filnamnet. Servern tar emot filen med dess faktiska MIME-typ, bestämd av webbläsaren, och kan kontrollera den på backend-sidan. application/octet-stream tillämpas för filer av okänd typ — webbläsaren försöker inte visa innehållet utan erbjuder att spara det på disk.

Content-Types påverkan på cachning

MIME-typen påverkar cachningspolicyn för CDN och webbläsare. Bilder med stabila URL:er cachas vanligtvis under lång tid (ett år eller mer), medan HTML-sidor — i minuter eller sekunder. CDN-servrar Cloudflare och Akamai använder Content-Type för att välja komprimeringsalgoritm: text/* komprimeras med gzip eller brotli, image/* — inte, eftersom bilder redan är komprimerade. Korrekt konfiguration av Content-Type på servern påverkar direkt laddningsprestandan för sidor och mobilapplikationer.

Hur server och klient använder Content-Type

Servern ställer in Content-Type-rubriken i HTTP-svaret baserat på typen av den begärda filen eller dynamiskt genererat innehåll. Populära webbservrar Nginx och Apache har inbyggda MIME-typtabeller som mappar filändelsen till motsvarande Content-Type. Till exempel får filen index.html text/html och style.css — text/css. För dynamiska svar ställer utvecklaren in Content-Type i applikationskoden i PHP, Python, Java eller Kotlin.

Klienten använder Content-Type för att välja hanterare. Om servern returnerar text/html startar webbläsaren HTML-parsern och bygger DOM-trädet. Om image/png — startar PNG-avkodaren. Om Content-Type saknas eller är felaktig tillämpar klienten MIME-sniffning — försöker gissa typen baserat på signaturen (magic bytes) i början av filen. JPEG börjar med byte FF D8 FF, PNG — med 89 50 4E 47 och PDF — med 25 50 44 46. Denna process är potentiellt farlig och inaktiveras av rubriken X-Content-Type-Options: nosniff.

I mobilapplikationer bearbetas Content-Type av HTTP-klienter. OkHttp på Android analyserar automatiskt Content-Type-rubriken från svaret och tillhandahåller den via metoden Response.header("Content-Type"). iOS-klienten URLSession gör samma sak via egenskapen URLResponse.mimeType. På båda plattformarna används Content-Type för att välja parser: JSON — via Moshi eller Gson på Android, via Codable på iOS; bilder — via Glide, Coil eller SDWebImage.

Innehållsförhandling via Accept och Content-Type

Content negotiation (innehållsförhandling) — en HTTP-mekanism där klienten anger önskat svarformat via Accept-rubriken och servern väljer lämpligt format och returnerar det med motsvarande Content-Type. Till exempel skickar klienten Accept: application/json, servern svarar med Content-Type: application/json. Om servern inte kan tillhandahålla det begärda formatet returnerar den 406 Not Acceptable. I REST API tillåter denna mekanism en endpoint att returnera data i JSON, XML eller HTML.

Content-Type i förfrågningar och svar

Content-Type-rubriken används både i HTTP-förfrågningar (Request) och i HTTP-svar (Response). I förfrågningar anger den formatet på förfrågans brödtext, till exempel vid sändning av JSON via POST. I svar — formatet på returnerade data. Den grundläggande skillnaden är att förfrågans Content-Type ställs in av klienten medan svarets Content-Type — av servern. Felaktig inställning av Content-Type i en förfrågan gör att servern inte kan tolka brödtexten och returnerar fel 400 Bad Request eller 415 Unsupported Media Type.

I HTTP-förfrågningar är Content-Type obligatorisk för metoderna POST, PUT och PATCH om förfrågan innehåller en brödtext (body). GET, HEAD och DELETE använder vanligtvis inte brödtext, så Content-Type för dem anges inte eller ignoreras. Vid sändning av ett HTML-formulär med attributet enctype="multipart/form-data" ställer webbläsaren automatiskt in Content-Type: multipart/form-data med en unik gränssträng (boundary) som separerar delarna av den sammansatta begäran. Varje del separeras med --boundary och slutet av begäran markeras med --boundary--.

I HTTP-svar ställs Content-Type in av servern. Om servern inte anger Content-Type aktiverar klienten antingen MIME-sniffning eller bearbetar svaret som application/octet-stream. HTTP-metoden HEAD gör det möjligt att få svarsrubriker, inklusive Content-Type, utan att överföra brödtexten. Detta är användbart för att kontrollera resurstypen innan den laddas fullständigt. CDN-servrar kan skriva över Content-Type vid innehållstransformering — till exempel vid konvertering av bilder till 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("Typ: ${mediaType?.type}, Subtyp: ${mediaType?.subtype}")
    }
}

Content-Type i mobila HTTP-klienter

I mobil utveckling bearbetas Content-Type-rubriken automatiskt av HTTP-klienter. I OkHttp på Android ställs Content-Type in via RequestBody: val body = "{}".toRequestBody("application/json".toMediaType()). Retrofit hanterar Content-Type via annoteringar: @Body för JSON, @Part för multipart. På iOS ställer URLSession in Content-Type för HTTPBody och Alamofire gör detta via parametern encoding: JSONEncoding.default eller URLEncoding.default. Manuell inställning av Content-Type krävs vid arbete med råa sockets eller anpassade protokoll.

Fel vid arbete med Content-Type

Felaktig Content-Type — ett av de vanligaste problemen vid utveckling och integration av webbtjänster. Det vanligaste felet är när servern returnerar text/html istället för application/json. Klienten får JSON som en HTML-sträng, kan inte tolka den och kastar ett undantag. Detta händer när webbramverket är som standard konfigurerat för HTML och utvecklaren glömmer att åsidosätta Content-Type för API-endpointen. I PHP visar det sig genom avsaknad av header('Content-Type: application/json'), i Spring Boot — genom avsaknad av annoteringen produces.

Det näst vanligaste felet är felaktig eller saknad charset. Om servern skickar text/html; charset=iso-8859-1 och webbläsaren förväntar sig UTF-8 visas kyrilliska tecken förvanskade. Detta problem är typiskt för gamla webbplatser som inte har gått över till UTF-8. För JSON förekommer sådant fel mer sällan eftersom RFC 8259 föreskriver UTF-8 utan ytterligare överenskommelse. Lösning — ange alltid explicit charset=utf-8 för textbaserade MIME-typer i serverkonfigurationen.

Det tredje problemet — diskrepans mellan Content-Type och faktiskt innehåll. Om servern skickar Content-Type: image/png men svarstexten innehåller en WebP-bild kanske webbläsaren inte kan avkoda den. CDN-servrar komprimerar ibland bilder med formatändring men uppdaterar inte Content-Type-rubriken. Kontroll av överensstämmelse mellan Content-Type och faktiskt innehåll är en obligatorisk fas i API-testning och integrationstestning av mobilapplikationer.

Diagnostik och korrigering av Content-Type-fel

Använd webbläsarens utvecklingsverktyg (fliken Network), curl med flaggan -I för att kontrollera svarsrubriker eller trafiksniffrar som Charles Proxy och Wireshark för felsökning. Nginx konfigureras via direktivet include mime.types, Apache — via AddType och AddDefaultCharset. För statiska filer, kontrollera alltid att filändelsen motsvarar dess MIME-typ. För dynamiska svar, ställ explicit in Content-Type innan data skrivs ut i alla programmeringsspråk — detta förhindrar den överväldigande majoriteten av problem.