Content type identification

Ensures receivers correctly parse JSON payloads by declaring the standardized media type at protocol boundaries.

REST APIs: setting the Content-Type header on HTTP responses carrying JSON bodies HTTP clients: declaring the request body format when POSTing or PUTing JSON File uploads and storage: identifying JSON-formatted blobs in multipart bodies or object stores

REST APIs, HTTP clients and servers, web frameworks (Express, Flask, Spring), OpenAPI/Swagger specs, GraphQL transports, cloud object storage, browser fetch API

Content-Type: application/json

• Content-Type header
• Accept header
• fetch API
• requests.post(...
• json=...)
• res.json()
• axios.post()
• express.json()
• OpenAPI requestBody content map

• application/x-www-form-urlencoded: used for HTML form submissions instead of structured JSON text/json: non-standard legacy variant that some servers reject application/vnd.api+json: vendor-specific variant for JSON:API specification application/hal+json: HAL hypermedia format built on JSON

Using text/json: non-standard MIME type, many servers and proxies reject it — cause: outdated tutorials, consequence: 415 Unsupported Media Type errors Forgetting the header entirely on POST: cause: assuming the server infers format, consequence: server defaults to form parser and body arrives as raw string Setting application/json but sending form-encoded body: cause: mismatched serialization, consequence: server-side parser throws or returns empty object Adding charset=utf-8 unnecessarily in some clients: cause: copy-paste from older specs, consequence: harmless but signals confusion about JSON's UTF-8 default Confusing application/json with application/javascript: cause: similar naming, consequence: browsers may try to execute the payload as script

application/xml: XML data format, requires explicit parser choice text/plain: unstructured text, no parsing contract multipart/form-data: binary file uploads and mixed form fields application/octet-stream: opaque binary blob with no format hint

Coming from older web stacks: may use text/json — application/json is the IANA-registered standard and the only universally accepted variant Coming from XML-heavy enterprise APIs: may default to application/xml — JSON APIs require application/json or a vendor-specific JSON subtype Coming from PHP/legacy CMS: may omit Content-Type entirely and rely on server heuristics — modern APIs reject requests without an explicit content type

• MIME types
• Content-Type header
• Accept header
• JSON serialization
• content negotiation

When NOT to use: when the payload is not JSON (XML, form-encoded, binary, protobuf) — using application/json with mismatched body causes parse failures. Performance: zero measurable overhead; it is a static header string. Boundary conditions: some servers accept the parameter form application/json; charset=utf-8, but JSON is UTF-8 by RFC 8259 so the parameter is redundant; vendor suffixes like application/vnd.api+json+xml are invalid and must not be combined.

Enables reliable content negotiation across HTTP boundaries so that clients and servers agree on parsing without out-of-band coordination, preventing silent data corruption, 415 errors, and integration failures in production APIs.

application/json is the universal passport stamped on every JSON payload crossing an HTTP border — without it, the receiving customs office has no idea what language the cargo speaks.

Content negotiation with vendor-specific JSON subtypes (application/vnd.api+json, application/hal+json, application/ld+json) and structured syntax suffixes (application/problem+json)