MIME Type Lookup

It tells the receiving end what a stream of bytes actually is. A browser does not look at the file extension of something it downloaded over HTTP: it reads the Content-Type header. Get it wrong and a stylesheet is ignored, a script refuses to run, or a PDF opens as gibberish.

On text based types: HTML, CSS, JavaScript, plain text, CSV, JSON and SVG. Without it, the browser has to guess the encoding, and a wrong guess is exactly how Turkish characters turn into mojibake. Binary types like images do not take a charset.

text/javascript. It was the other way round for years, which is why both are everywhere, but the current specification makes text/javascript the standard one and marks application/javascript obsolete. Both work in every browser.

Bytes we cannot describe any further. It is the correct answer for genuinely unknown data and the wrong answer for anything you do know, because browsers respond to it by downloading rather than displaying. A PDF served as octet-stream downloads instead of opening in the viewer.

Almost always because it is served as text/plain or as octet-stream. SVG must be image/svg+xml or the browser treats it as text. This is the single most common MIME misconfiguration on static hosts.

Because the extension is genuinely ambiguous: it is TypeScript source to a developer and an MPEG transport stream to a video player. Servers usually have to be told which one you mean, and serving TypeScript source to a browser is rarely what you want anyway.

No. The type in a multipart upload is supplied by the client and can say anything. Check the actual file signature on the server, and never decide what to do with a file based on a header the uploader controls.

In your web server or CDN. Nginx reads a mime.types file, Apache uses AddType, and most static hosts infer it from the extension. When something behaves oddly, the network panel shows what was actually sent, which is usually different from what you assumed.