Content-Type Checker

The Content Type Checker reveals the exact HTTP Content-Type header value that an image should carry, derived from the file's real bytes rather than from assumptions about its name. It is built for developers wiring up servers, CDN rules, upload validators and media pipelines where the header string must be byte-for-byte correct.

Content-Type is the header a server sends ahead of a response to tell the client what is coming. When a browser requests a JPEG, the response carries something like Content-Type: image/jpeg, and the consumer decides how to render, decode or save based on that line. A wrong value does not corrupt the file, but it commands every intermediary - browsers, proxies, security scanners, mobile clients - to treat it incorrectly.

The header is only as accurate as its source. Servers usually assemble Content-Type from the file extension using a mapping table, so a mislabeled file inherits its label's header regardless of its true content. This tool cuts around that by sniffing the signature in the leading bytes and returning the header string that belongs to what the file actually is.

The output is deliberate about spelling: the returned value is the canonical image/jpeg, not the informal image/jpg. That distinction matters because header strings are compared literally in browsers and validators, and a variant no validator recognizes behaves like no header at all. Every returned string is copy-ready for configuration.

Use it when configuring an origin server or CDN, when debugging a browser that downloads a file instead of rendering it, when a strict upload validator rejects valid-looking images, and whenever you are about to write a Content-Type into a config table and want the exact registered value. It supports the core web display formats - JPG, PNG, WebP, AVIF, GIF and SVG.

Nothing is uploaded and nothing is modified. The file is read locally for a quick signature check, the header string is produced, and the original stays exactly as you found it. The bottleneck in the entire flow is your own decision about where to paste the resulting value.

Each supported format wires to one canonical header value-complete with the Content-Type: prefix ready for a config line or a test. The mapping below is the common ground between browser expectations and server practice, aligned to the registered MIME strings for each format.

Notice the corrections baked into the table. The base UTF-8 image/svg+xml stands in for charset-laden variants, and image/jpeg is used rather than image/jpg - both choices exist so the string you copy is the one a conforming client expects.

Header comparison is literal: image/jpg and image/jpeg are different strings even though they describe the same family of files. When a validator, CDN or mobile client matches against a fixed set that contains only image/jpeg, a header announcing image/jpg simply is not recognized, and the response falls back to whatever behavior a missing match allows - often a forced download or a refusal to render.

The same literal-comparison trap awaits charset variants. A header written as image/svg+xml; charset=utf-8 is not equal to image/svg+xml, and split-again parsers may not reassemble them. Shipping one canonical value and one only is the reliable path, which is why this tool always returns the bare registered string.

The failure mode is central to why this tool exists: the file can be flawless while the header makes it unusable. A browser that receives image/png for a PNG that is actually decoded fine still misbehaves if the header mismatch trips sniffing protections, forces a download dialog, or makes a strict origin refuse to process the response.

The classic symptoms below all share an innocent-looking file and a wrong transport label. Running the content type check puts the name and the bytes back in agreement so the transport disappears as a variable.

• A JPEG served as image/jpg triggers a download dialog instead of an inline render.
• A PNG served with application/octet-stream is treated as an opaque download.
• An SVG served without image/svg+xml opens in a text viewer or is rejected outright.
• A mislabeled JPEG (named .png) inherits image/png and confuses every decoder.
• A WebP served with the wrong header forces clients into sniffing or failure.

Most servers build Content-Type from an extension mapping: .jpg becomes image/jpeg, .png becomes image/png, and so on. That is cheap and deterministic, but the mechanism cannot notice when the name lied. A photo.jpg that is actually PNG is served as image/jpeg with absolute confidence in the config table.

Byte-based detection starts from the other side. The leading signature resolves the true format, and the header is chosen from the format's canonical value. The result is that the header follows the content, not the name - which is the property you want when the goal is accurate responses.

The most common destination for the returned value is a header rule: a static file handler, a CDN rule, or an upload validator that expects a declared type. Where this value should land depends on the layer doing the serving, but the copy-ready line works almost anywhere you paste it verbatim.

A deliberately small support set - the modern web display formats - keeps the mapping unambiguous. JPG, PNG, WebP, AVIF, GIF and SVG cover the overwhelming majority of production image traffic, and each one maps to exactly one header value with no ambiguity.

• Static file servers: define the extension-to-header mapping using these values.
• Upload validators: compare the declared header against the signature result.
• CDN rules: normalize the origin header to the canonical value before caching.
• Test suites: assert the response header equals the expected string.

Scope discipline keeps the output trustworthy. This tool returns the header value for the supported formats and stops there: it does not evaluate image quality, does not validate pixel data, and does not police the correctness of remote servers. Its read is local signature detection plus a strict mapping.

If your need is broader format identity - TIFF, BMP, ICO, or the sort of mystery file that belongs in a forensic pass - the MIME Type Checker and the Image Format Checker cover the wider table. Keep this tool for the focused job it names in its title.