MIME-Type-Finder: Magic-Byte + Server-Config-Export

Was macht der MIME-Type-Finder?

Der Finder ist ein bidirektionales Lookup-Tool plus Magic-Byte-Erkenner für MIME-Types. Du suchst nach einer Dateiendung (.webp, .heic, .wasm) und bekommst den kanonischen MIME plus Alias-Liste, oder du gibst einen MIME (image/webp, application/wasm) ein und siehst die zugeordneten Endungen mit der „canonical first“-Markierung. Beide Richtungen sind in einem Eingabefeld vereint, weil das die häufigste Frage ist: „welcher Content-Type für .webp?“ oder umgekehrt „welche Endung kommt aus audio/ogg?“.

Pro Eintrag zeigt der Tool: den IANA-Status (registriert oder deprecated alias), die kanonische und alternative Endungen, eine ein-Satz-Erklärung des Formats, optional Browser-Support für moderne Codecs (AVIF, HEIC, JXL, WOFF2, WebAssembly), und das Magic-Byte-Muster zur Erkennung.

Wie funktioniert die Magic-Byte-Erkennung?

Datei in den Drop-Bereich ziehen, die ersten 32 bis 64 Bytes werden lokal via FileReader gelesen und gegen die Signatur-Tabelle abgeglichen. JPEG erkennt sich an FF D8 FF am Datei-Anfang, PNG an 89 50 4E 47 0D 0A 1A 0A, PDF an 25 50 44 46 (ASCII „%PDF“), WebAssembly an 00 61 73 6D. Container- Formate wie HEIC, AVIF und MP4 nutzen die ISO-Base-Media-Boxen mit dem ftyp-Marker ab Byte 4, der Brand-String dahinter (heic, avif, isom, mp42) entscheidet, welche konkrete Variante vorliegt.

Der Drop ist autoritativ: Wenn der Dateiname .jpg sagt, die Bytes aber 89 50 4E 47 lauten, erscheint eine Mismatch-Warnung. Bytes lügen nicht, eine Datei kann jederzeit umbenannt sein. Das ist die einzige zuverlässige Methode, einen MIME-Type für Upload-Validation zu prüfen, wenn die User-Agent-Headers nicht vertrauenswürdig sind.

Was ist der Unterschied zwischen IANA-registriert und x--Aliasen?

IANA-registrierte MIME-Types stehen in der offiziellen Media Types Registry und sind formal über RFC 6838 standardisiert. Das vnd.-Präfix markiert Vendor-spezifische Codes (z.B. application/vnd.ms-excel für .xls), die einem konkreten Hersteller zugeordnet sind. Das x--Präfix dagegen war früher für „experimentell“ gedacht, wurde aber 2012 mit RFC 6648 als Anti-Pattern deklariert: neue Codes sollen direkt registriert werden, nicht erst als x- erscheinen.

Praktisch gibt es 2026 noch Duplikate: image/x-icon (legacy, browser-toleriert) vs image/vnd.microsoft.icon (IANA-registriert seit 2003), oder application/x-rar-compressed (deprecated) vs application/vnd.rar (IANA seit 2014). Der Tool-Filter „nur IANA-registriert“ blendet die x--Aliase aus, damit neue Server- Configs den modernen Code nutzen. Existing Servers sollten beide Varianten akzeptieren, Browser senden historisch oft das legacy-Präfix.

Welche modernen Formate deckt der Finder 2026 ab?

Die Datenbank kennt die wichtigsten neuen Codecs der letzten Jahre, inklusive Browser-Support-Daten aus Can I Use:

• Bild: AVIF (image/avif, AV1-basiert, Chrome 85+/Firefox 93+/Safari 16+), HEIC (image/heic, HEVC-basiert, Safari 17+), JXL (image/jxl, royalty-free, Firefox 111+/Safari 17+), WebP (image/webp, ubiquitous).
• Audio: Opus (audio/opus, low-latency, RFC 6716), FLAC (audio/flac).
• Video: AV1 (video/av1, royalty-free, Chrome 70+/Firefox 67+/Safari 17+), WebM-Container.
• Font: WOFF2 (font/woff2, Brotli-komprimiert, die kanonische Web-Font seit 2018).
• Application: WebAssembly (application/wasm, Pflicht für Streaming-Compilation), Web-App-Manifest (application/manifest+json, Pflicht für PWA-Install-Banner), JSON-LD (application/ld+json, schema.org structured data), Zstandard (application/zstd, IANA 2018).
• 3D-Modell: glTF binary (model/gltf-binary, single-file 3D-Asset für WebGL/three.js).

Der Toggle „Nur moderne Formate“ filtert auf diese 2018-2026-Additionen, nützlich beim Build eines modernen Static-Asset-Servers, der die alten DCT-/RGB-/Indexed-Formate ignorieren darf.

Welche Server-Configs kann der Finder exportieren?

Fünf Targets, alle aus der aktuellen Filter-Selektion generiert:

• Apache mime.types: ein-MIME-pro-Zeile-Format, Endungen leerzeichen-separiert. Direkt in die Server-Config dropbar.
• nginx types { }: Block für http {} oder server {}-Kontext, mit korrekten Semikolons.
• IIS web.config: <staticContent>-XML mit <mimeMap>-Elementen für jedes Endung-MIME-Paar.
• Express/Koa-Middleware: JavaScript-Snippet mit MIME_BY_EXT-Map und setHeaders-Funktion, die in express.static-Optionen gehängt werden kann.
• Cloudflare-Worker: Default-fetch-Handler, der den Content-Type-Response-Header basierend auf der URL-Endung umschreibt, nützlich, wenn die Origin den falschen MIME sendet.

Workflow: Kategorie + IANA + Modern-Filter setzen, dann Export-Tab wählen. Der Tool zeigt das Snippet live an, der „Kopieren“-Button legt es in die Zwischenablage, „Herunterladen“ speichert es als Datei mit der server-typischen Endung (mime.types, web.config, mime.types.conf, .js).

Welche Magic-Byte-Signaturen kennt der Finder?

Mehr als 40 Format-Signaturen, gruppiert nach Komplexität:

• Trivial (1-4 Bytes am Offset 0): JPEG (FF D8 FF), PNG (89 50 4E 47 0D 0A 1A 0A), GIF (47 49 46 38 37 61 oder …39 61), PDF (25 50 44 46), ZIP/OOXML (50 4B 03 04), 7z (37 7A BC AF 27 1C), Gzip (1F 8B), bzip2 (42 5A 68), Zstandard (28 B5 2F FD).
• RIFF-Container (mit Wildcard-Bytes für Size): WebP (RIFF????WEBP), WAV (RIFF????WAVE), AVI (RIFF????AVI ).
• ISO-Base-Media-Boxen (am Offset 4 nach Size-Prefix): MP4 (ftypisom, ftypMSNV, ftypmp42), HEIC (ftypheic, ftypheix, ftypmif1), AVIF (ftypavif), QuickTime (ftypqt ), 3GPP (ftyp3gp4).
• WebAssembly: 00 61 73 6D plus 4-Byte-Versions-Feld.
• Font-Container: WOFF (wOFF), WOFF2 (wOF2), TrueType (00 01 00 00), OpenType (OTTO), Font-Collection (ttcf).
• Office Legacy: OLE Compound (D0 CF 11 E0 A1 B1 1A E1) für .doc/.xls/.ppt/.msi.
• Archive: RAR v4 (52 61 72 21 1A 07 00), RAR v5 (52 61 72 21 1A 07 01 00), Debian (!<arch>), RPM (ED AB EE DB).

Die Wildcard-Syntax ?? erlaubt variable Bytes mitten in einer Signatur, bei RIFF-Containern ist das die 4-Byte-Größenangabe, die je nach Datei anders ist. Das ist die gleiche Notation wie in der PHP finfo-Magic-Datenbank und dem Unix-file(1)-Tool.

Wie privat ist die Bytes-Erkennung?

Pure-client von Anfang bis Ende. Die komplette MIME-Datenbank ist im JavaScript-Bundle eingebettet (unter 50 KB minified), die Such- und Filter-Logik läuft im Hauptthread. Beim Datei-Drop liest die FileReader-API die ersten 32-64 Bytes in einen Uint8Array im RAM, die Datei selbst wird nicht weiter angetastet, das Lesen passiert client-seitig, keine Bytes verlassen den Browser. Wenn du die Verifikation siehst willst: F12 öffnen, Tab „Netzwerk“, Datei in den Drop-Bereich ziehen, keine zusätzlichen Requests werden gesendet.

Der Server-Config-Export passiert ebenfalls pure-JS: die ausgewählten Einträge werden zu String-Snippets formatiert, der Copy-Button nutzt die Clipboard-API, der Download-Button erzeugt einen Blob-Object-URL. Kein Backend, kein Login, kein Telemetrie-Pixel.

Was deckt der Finder bewusst NICHT ab?

Der Tool ist kein Konvertierer und kein vollwertiger libmagic-Port. Bewusste Lücken:

• Keine Server-seitige Tief-Inspektion: der Unix-file(1)-Befehl kennt tausende Format-Varianten über regelbasierte Heuristiken (Position-abhängige Strings, mehrere Offsets, Längen-Berechnungen). Das wäre eine eigene Tool-Familie wert, der Finder beschränkt sich auf die Magic-Bytes mit hohem Treffer-Erfolg pro Byte.
• Keine Bulk-Datei-Analyse mit Download-Report: nur Einzel-Drop. Wer hundert Dateien gleichzeitig prüfen will, braucht ein CLI-Tool.
• Kein HTTP-Header-Sniffing-Demo: eine fremde URL fetchen und ihren Content-Type lesen wäre hilfreich, scheitert aber an CORS und Privacy-Implikationen. Der Tool bleibt rein lokal.
• Keine Konvertierung: wer ein PNG zu WebP umrechnen will, nutzt den entsprechenden Konverter. Der Finder identifiziert nur, er ändert nicht.

Wer eine Format-Konvertierung sucht, findet die passenden Tools in der Bild-, Audio- und Video-Kategorie.