Content-Type in der Webentwicklung: Was es ist, MIME-Typen und wie es funktioniert

Was ist Content-Type?

Content-Type ist ein HTTP-Header aus der Gruppe der Repräsentationsheader, der dem Empfänger das Format der Daten im Nachrichtentext mitteilt. Er ist für HTTP-Anfragen und -Antworten, die einen Body enthalten, obligatorisch, und ohne ihn kann der Client die empfangenen Bytes nicht korrekt interpretieren. Basierend auf Content-Type wählt der Browser oder die mobile App einen Parser aus: Bei text/html wird die HTML-Engine gestartet, bei image/png der PNG-Decoder und bei application/json der JSON-Parser.

Der Content-Type-Wert ist ein MIME-Typ — ein standardisierter Identifikator für Datenformate. Das Akronym MIME steht für Multipurpose Internet Mail Extensions, da dieser Standard ursprünglich für E-Mail-Anhänge entwickelt wurde. Er wurde jedoch zur Grundlage von HTTP und wird heute überall verwendet — von der Übertragung von Webseiten bis zum Datenaustausch in REST-APIs. Jeder MIME-Typ besteht aus zwei Teilen: einer Hauptkategorie und einem qualifizierenden Subtyp, getrennt durch einen Schrägstrich.

Der charset-Parameter ergänzt Content-Type für Textformate. Content-Type: text/html; charset=utf-8 bedeutet beispielsweise, dass ein HTML-Dokument in UTF-8-Kodierung übertragen wird. Laut IETF RFC 7231, Abschnitt 3.1.1.5, ist der Content-Type-Header für HTTP-Nachrichten mit einem Body obligatorisch, und sein Fehlen wird als application/octet-stream behandelt oder führt zu MIME Sniffing.

Geschichte der MIME-Typen in HTTP

Das HTTP/0.9-Protokoll, das 1991 veröffentlicht wurde, übertrug nur HTML-Seiten, sodass der Datentyp standardmäßig implizit war. Mit der Einführung von HTTP/1.0 in RFC 1945 erkannten Entwickler die Notwendigkeit, Bilder, Stylesheets und Skripte zu übertragen. Sie passten den MIME-Standard aus dem E-Mail-Protokoll an, und Content-Type wurde ein integraler Bestandteil von HTTP. Seitdem ist das IANA-Register auf Hunderte von Werten angewachsen — vom vertrauten text/html bis zu modernen image/avif und application/manifest+json.

Die Rolle von Content-Type in der Sicherheit

Content-Type spielt eine entscheidende Rolle beim Schutz vor Angriffen. Wenn ein Server eine HTML-Datei mit dem MIME-Typ text/plain sendet, führt der Browser kein JavaScript aus und erstellt kein DOM — dies verhindert XSS-Angriffe. Der von OWASP empfohlene X-Content-Type-Options: nosniff-Header verbietet dem Browser vollständig, den MIME-Typ anhand des Inhalts zu erraten. Laut PortSwigger Research waren MIME-Sniffing-Angriffe besonders im Internet Explorer 6-9 verbreitet, wo der Browser Content-Type ignorierte und den Typ anhand der ersten Bytes der Datei bestimmte.

Aufbau des MIME-Typs

Ein MIME-Typ wird im Format type/subtype angegeben, wobei type die allgemeine Datenkategorie und subtype das spezifische Format darin ist. In image/png gibt beispielsweise die Kategorie image ein Bild an und der Subtyp png das Format Portable Network Graphics. Es gibt nur wenige Kategorien: text, image, audio, video, application, multipart und message. Die restliche Vielfalt kommt von den Subtypen, von denen es Hunderte gibt.

Zusätzliche Parameter werden durch ein Semikolon nach dem Subtyp übergeben. Der häufigste Parameter ist charset zur Angabe der Kodierung. Content-Type: application/json; charset=utf-8 zeigt an, dass ein JSON-Dokument in UTF-8-Kodierung übertragen wird. Formal ist charset für application/json überflüssig, da JSON gemäß RFC 8259 immer in UTF-8 vorliegt, aber die explizite Angabe verbessert die Kompatibilität mit älteren HTTP-Clients.

Standard- und nicht standardisierte MIME-Typen

Standard-MIME-Typen sind im IANA-Register registriert und haben ein Hauptkategorie-Präfix. Nicht standardisierte (anbieterspezifische) Typen verwenden das x- Präfix oder das Format vnd.company.type — z. B. application/vnd.google-earth.kml+xml für das KML-Format von Google. Browser erkennen nicht standardisierte Typen möglicherweise nicht, daher wird für unbekannte Anhänge application/octet-stream verwendet — ein universeller Binärstrom, den der Browser nicht anzuzeigen versucht, sondern zum Herunterladen als Datei anbietet.

Der charset-Parameter in der Praxis

Der charset-Parameter ist für die korrekte Textanzeige entscheidend. Ohne ihn kann der Browser Zeichen falsch interpretieren, was zu Mojibake führt. Der Standard für das Web ist UTF-8, aber es kommen auch ISO-8859-1 (Latin-1) für westeuropäische Sprachen und windows-1251 für Kyrillisch auf älteren Websites vor. Die W3C-Empfehlung lautet, für text/html und text/plain immer charset=utf-8 anzugeben, während charset für application/json nicht erforderlich ist.

Wichtige Content-Type-Typen

In der Praxis arbeiten Webentwickler und Mobile-Entwickler mit einer begrenzten Anzahl von MIME-Typen. Die Kenntnis dieser Typen ist für die korrekte Serverkonfiguration, das Schreiben von HTTP-Clients und die Verarbeitung statischer Dateien unerlässlich. text/html ist der Haupttyp für Webseiten, der von Apache- und Nginx-Servern standardmäßig für HTML-Dateien zurückgegeben wird. application/xhtml+xml wird seltener verwendet und nur für XHTML-Dokumente.

application/json ist zum Standard für REST-APIs geworden. Server geben JSON-Daten mit diesem MIME-Typ zurück, und Clients senden ihn in POST- und PUT-Anfragen. text/javascript (veraltet) und application/javascript werden für JavaScript-Dateien verwendet. Laut W3Techs Survey, 2025 ist JSON das am schnellsten wachsende Datenformat im Web und hat XML im Jahr 2018 überholt. Für SOAP-Dienste werden weiterhin text/xml oder application/soap+xml verwendet.

Bei Bildern wird der MIME-Typ durch das Dateiformat bestimmt: image/jpeg für JPEG, image/png für PNG, image/gif für GIF, image/webp für das moderne WebP-Format. image/svg+xml wird für Vektorgrafiken verwendet und unterstützt eingebettete Stile und Skripte. video/mp4, audio/mpeg und application/pdf sind weitere häufig vorkommende Typen. Für Webschriften werden font/woff2, font/woff und font/ttf verwendet.

Content-Type beim Dateiupload

Beim Hochladen von Dateien über ein HTML-Formular wird multipart/form-data verwendet — ein zusammengesetzter MIME-Typ, der die Anfrage in mehrere Teile aufteilt. Jeder Teil hat einen eigenen Content-Type-Header und Content-Disposition, die den Feldnamen und den ursprünglichen Dateinamen angeben. Der Server empfängt die Datei mit ihrem vom Browser ermittelten tatsächlichen MIME-Typ und kann ihn auf der Backend-Seite überprüfen. application/octet-stream wird für Dateien unbekannten Typs verwendet — der Browser versucht nicht, den Inhalt anzuzeigen, sondern bietet an, ihn auf der Festplatte zu speichern.

Auswirkungen von Content-Type auf das Caching

Der MIME-Typ beeinflusst die Caching-Richtlinie von CDN und Browsern. Bilder mit stabilen URLs werden normalerweise für einen langen Zeitraum (ein Jahr oder mehr) zwischengespeichert, während HTML-Seiten für Minuten oder Sekunden zwischengespeichert werden. CDN-Server wie Cloudflare und Akamai verwenden Content-Type zur Auswahl des Komprimierungsalgorithmus: text/* wird mit gzip oder brotli komprimiert, image/* nicht, da Bilder bereits komprimiert sind. Die korrekte Content-Type-Konfiguration auf dem Server wirkt sich direkt auf die Ladeleistung von Webseiten und mobilen Anwendungen aus.

Wie Server und Client Content-Type nutzen

Der Server setzt den Content-Type-Header in der HTTP-Antwort basierend auf dem Typ der angeforderten Datei oder dynamisch generierten Inhalt. Beliebte Webserver wie Nginx und Apache haben eingebaute MIME-Typ-Tabellen, die Dateierweiterungen dem entsprechenden Content-Type zuordnen. Beispielsweise erhält index.html text/html und style.css text/css. Für dynamische Antworten setzt der Entwickler Content-Type im Anwendungscode in PHP, Python, Java oder Kotlin.

Der Client verwendet Content-Type zur Auswahl eines Handlers. Wenn der Server text/html zurückgibt, startet der Browser den HTML-Parser und erstellt den DOM-Baum. Bei image/png startet er den PNG-Decoder. Wenn Content-Type fehlt oder falsch ist, wendet der Client MIME Sniffing an — er versucht, den Typ anhand der Signatur (Magische Bytes) am Anfang der Datei zu erraten. JPEG beginnt mit den Bytes FF D8 FF, PNG beginnt mit 89 50 4E 47 und PDF beginnt mit 25 50 44 46. Dieser Prozess ist potenziell gefährlich und wird durch den X-Content-Type-Options: nosniff-Header deaktiviert.

In mobilen Anwendungen wird Content-Type von HTTP-Clients verarbeitet. OkHttp auf Android analysiert automatisch den Content-Type-Header aus der Antwort und stellt ihn über die Methode Response.header("Content-Type") bereit. Der iOS-URLSession-Client macht dasselbe über die Eigenschaft URLResponse.mimeType. Auf beiden Plattformen wird Content-Type zur Auswahl eines Parsers verwendet: JSON — über Moshi oder Gson auf Android, über Codable auf iOS; Bilder — über Glide, Coil oder SDWebImage.

Content Negotiation über Accept und Content-Type

Content Negotiation ist ein HTTP-Mechanismus, bei dem der Client das gewünschte Antwortformat über den Accept-Header angibt und der Server das entsprechende Format auswählt und mit dem passenden Content-Type zurückgibt. Beispielsweise sendet der Client Accept: application/json, der Server antwortet mit Content-Type: application/json. Wenn der Server das angeforderte Format nicht bereitstellen kann, gibt er 406 Not Acceptable zurück. In REST-APIs ermöglicht dieser Mechanismus einem einzelnen Endpunkt, Daten in JSON, XML oder HTML zurückzugeben.

Content-Type in Anfragen und Antworten

Der Content-Type-Header wird sowohl in HTTP-Anfragen als auch in HTTP-Antworten verwendet. In Anfragen gibt er das Format des Anfragekörpers an, z. B. beim Senden von JSON über POST. In Antworten gibt er das Format der zurückgegebenen Daten an. Der wesentliche Unterschied besteht darin, dass der Content-Type der Anfrage vom Client und der Content-Type der Antwort vom Server gesetzt wird. Eine falsche Einstellung von Content-Type in einer Anfrage führt dazu, dass der Server den Körper nicht parsen kann und einen 400 Bad Request oder 415 Unsupported Media Type Fehler zurückgibt.

In HTTP-Anfragen ist Content-Type für die Methoden POST, PUT und PATCH obligatorisch, wenn die Anfrage einen Body enthält. GET, HEAD und DELETE verwenden normalerweise keinen Body, daher wird Content-Type für sie nicht angegeben oder ignoriert. Beim Senden eines HTML-Formulars mit dem Attribut enctype="multipart/form-data" setzt der Browser automatisch Content-Type: multipart/form-data mit einer eindeutigen Grenzzeichenfolge (Boundary), die die Teile der zusammengesetzten Anfrage trennt. Jeder Teil wird durch --boundary getrennt, und das Ende der Anfrage wird durch --boundary-- markiert.

In HTTP-Antworten wird Content-Type vom Server gesetzt. Wenn der Server keinen Content-Type angibt, aktiviert der Client entweder MIME Sniffing oder verarbeitet die Antwort als application/octet-stream. Die HTTP-HEAD-Methode ermöglicht das Abrufen von Antwortheadern einschließlich Content-Type ohne Übertragung des Körpers. Dies ist nützlich, um den Ressourcentyp vor dem vollständigen Laden zu überprüfen. CDN-Server können Content-Type bei der Transformation von Inhalten überschreiben — z. B. bei der Konvertierung von Bildern in 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 in mobilen HTTP-Clients

In der mobilen Entwicklung wird der Content-Type-Header automatisch von HTTP-Clients verarbeitet. In OkHttp auf Android wird Content-Type über RequestBody gesetzt: val body = "{}".toRequestBody("application/json".toMediaType()). Retrofit verwaltet Content-Type über Annotationen: @Body für JSON, @Part für Multipart. Unter iOS setzt URLSession Content-Type für HTTPBody, und Alamofire tut dies über den Parameter encoding: JSONEncoding.default oder URLEncoding.default. Die manuelle Einstellung von Content-Type ist bei der Arbeit mit Raw-Sockets oder benutzerdefinierten Protokollen erforderlich.

Content-Type-Fehler

Ein falscher Content-Type ist eines der häufigsten Probleme bei der Entwicklung und Integration von Webdiensten. Der häufigste Fehler tritt auf, wenn der Server text/html anstelle von application/json zurückgibt. Der Client empfängt JSON als HTML-String, kann ihn nicht parsen und löst eine Ausnahme aus. Dies geschieht, wenn das Web-Framework standardmäßig für HTML konfiguriert ist und der Entwickler vergisst, Content-Type für API-Endpunkte zu überschreiben. In PHP zeigt sich dies, wenn header('Content-Type: application/json') fehlt, in Spring Boot — wenn die produces-Annotation fehlt.

Der zweithäufigste Fehler ist ein falscher oder fehlender charset. Wenn der Server text/html; charset=iso-8859-1 sendet und der Browser UTF-8 erwartet, werden kyrillische Zeichen als Mojibake angezeigt. Dieses Problem ist typisch für ältere Websites, die nicht auf UTF-8 umgestellt wurden. Bei JSON tritt ein solcher Fehler seltener auf, da RFC 8259 UTF-8 ohne zusätzliche Aushandlung vorschreibt. Die Lösung besteht darin, in der Serverkonfiguration für Text-MIME-Typen immer explizit charset=utf-8 anzugeben.

Das dritte Problem ist die Nichtübereinstimmung von Content-Type mit dem tatsächlichen Inhalt. Wenn der Server Content-Type: image/png sendet, der Antworttext jedoch ein WebP-Bild enthält, kann der Browser es möglicherweise nicht dekodieren. CDN-Server komprimieren manchmal Bilder mit Formatänderung, aktualisieren aber den Content-Type-Header nicht. Die Überprüfung von Content-Type auf Übereinstimmung mit dem tatsächlichen Inhalt ist ein obligatorischer Schritt beim API-Testen und Integrationstesten mobiler Anwendungen.

Diagnose und Behebung von Content-Type-Fehlern

Verwenden Sie zum Debuggen die Entwicklertools des Browsers (Registerkarte Network), curl mit dem Flag -I zur Überprüfung der Antwortheader oder Traffic-Sniffer wie Charles Proxy und Wireshark. Nginx wird über die Direktive include mime.types konfiguriert, Apache — über AddType und AddDefaultCharset. Überprüfen Sie bei statischen Dateien immer, ob die Dateierweiterung mit ihrem MIME-Typ übereinstimmt. Setzen Sie bei dynamischen Antworten in allen Programmiersprachen vor der Datenausgabe explizit Content-Type — dies verhindert die überwiegende Mehrheit der Probleme.