Content-Type Checker

Check the Content-Type a URL actually returns. Enter an address and this tool reads the live header and breaks it into the MIME type (for example text/html or application/json) and the charset (such as utf-8), and shows whether X-Content-Type-Options: nosniff is set. A wrong content type is a common, hard-to-spot cause of garbled text, files opening as plain text, or downloads that should render.

How to use the Content-Type Checker

Enter a URL and press Check content type. The tool fetches the resource and reports:

• The MIME type on its own (for example text/html, application/json, image/webp).
• The declared charset, or a warning if a text response omits one.
• The full raw Content-Type header as sent.
• Whether X-Content-Type-Options: nosniff is present, which stops the browser overriding the declared type.

Point it at any resource — an HTML page, a JSON API, an image, a font, a downloadable file. The header it returns is exactly what the browser uses to decide how to handle the response.

What Content-Type controls

The Content-Type header is how a server tells the browser what kind of data it is sending. It has two parts: a MIME type like text/html or application/pdf, and an optional charset like ; charset=utf-8. The browser reads this before the body and decides everything downstream from it — render as a page, parse as JSON, show an image, or trigger a download.

Because so much hangs on this one header, a wrong value produces confusing bugs:

• Missing or wrong charset — a UTF-8 page served without charset=utf-8 may render accented characters, emoji and non-Latin scripts as mojibake. The bytes are fine; the browser just decoded them with the wrong table.
• Wrong MIME type — JSON served as text/plain can break API clients; a JavaScript file served as text/html is refused by strict browsers; a PDF served as application/octet-stream downloads instead of opening inline.
• MIME sniffing — when the type is missing or implausible, browsers historically guessed by inspecting the bytes. That guessing is itself a security risk (a file uploaded as an image but sniffed as HTML could run script), which is why X-Content-Type-Options: nosniff exists to forbid it.

The fix is almost always at the server or CDN: send the correct MIME type, add charset=utf-8 for text formats, and set nosniff so the browser trusts what you declared rather than guessing.

Common use cases

• Debugging garbled text — confirm whether a text response declares charset=utf-8 when characters render wrongly.
• Fixing API responses — verify a JSON endpoint returns application/json, not text/plain or text/html.
• Checking downloads vs inline — see why a file downloads instead of rendering, or vice versa.
• Validating asset types — confirm JS, CSS, fonts and images are served with their correct MIME types.
• Security hygiene — check that nosniff is set so the browser does not override the declared type.

Common MIME types worth knowing

• text/html; charset=utf-8 — web pages. Always include the charset.
• application/json — API responses. No charset needed; JSON is defined as UTF-8.
• text/css and text/javascript (or application/javascript) — stylesheets and scripts. Strict browsers reject scripts served as the wrong type.
• image/png, image/jpeg, image/webp, image/svg+xml — images. SVG is the one to watch, since it can contain script and should be served carefully.
• font/woff2 — web fonts.
• application/pdf — opens inline in most browsers; pair with Content-Disposition to force a download instead.
• application/octet-stream — generic binary; the browser will download it because it has no way to render it.