application/json JSON Flagship

What it's for

application/json identifies data formatted as JSON (JavaScript Object Notation) — by far the dominant data interchange format on the modern web. It's what nearly every REST API sends and expects today, replacing XML as the default choice for API payloads over the last decade because it's lighter, maps naturally onto JavaScript objects, and is trivially parseable in essentially every programming language.

Registered officially in RFC 8259, application/json has no meaningful competing alternative for its use case anymore — if you're building an API in 2026, this is very likely your default response Content-Type unless you have a specific reason to use something else (like application/ld+json for structured linked data, or GraphQL's own conventions).

Format & syntax

Set as the Content-Type header on both requests and responses:

Content-Type: application/json
Content-Type: application/json; charset=utf-8

JSON is text-based UTF-8 by default per spec, so the charset parameter is technically redundant — but many frameworks and clients still include it explicitly, and it's harmless either way. The body itself must be valid JSON: an object, array, string, number, boolean, or null at the top level, with double-quoted keys and strings (single quotes are invalid JSON, a very common beginner mistake).

How it's used in practice

• REST API requests and responses — the default content type for both sending data to an API (POST/PUT bodies) and receiving it back, paired with Accept: application/json on the request side to tell the server what format you want returned.
• Configuration files — package.json, composer.json, tsconfig.json, and countless other tool configs use JSON as their format, though the MIME type only matters when these are served over HTTP, not when read directly from disk.
• WebSocket message payloads — many WebSocket-based protocols serialize messages as JSON strings even though WebSocket itself doesn't have a MIME type concept the same way HTTP does.
• fetch/axios/HTTP client defaults — most modern HTTP client libraries default to serializing request bodies as JSON and parsing JSON responses automatically when this Content-Type is present, which is a large part of why it's become the path of least resistance for API design.

Common mistakes & gotchas

• Sending JSON without setting the Content-Type header — if you POST a JSON string but don't set Content-Type: application/json, some frameworks (particularly ones that inspect Content-Type to decide how to parse the request body) will fail to parse it as JSON at all, silently treating it as raw text or form data instead.
• Using single quotes instead of double quotes — valid in JavaScript object literals, invalid in JSON. A response body copy-pasted from JS code without converting quote style will fail to parse as JSON even though it looks nearly identical.
• Trailing commas — also valid-looking in JavaScript, invalid in strict JSON. A trailing comma in an array or object will cause a parse error in most JSON parsers, one of the most common "why won't this parse" bugs.
• Sending JSON but forgetting Accept: application/json on requests expecting JSON back — some APIs vary their response format based on the Accept header (content negotiation) and will return HTML or XML by default if you don't explicitly request JSON.

Comparison & FAQ

Do I need to specify a charset for application/json?

Not strictly — JSON is UTF-8 by default per RFC 8259, so application/json alone is sufficient. Many tools add ; charset=utf-8 explicitly anyway, which is harmless but redundant.

Why is my JSON request body not being parsed by the server?

Almost always a missing or incorrect Content-Type: application/json header — many server frameworks decide how to parse the request body based on this header, so without it, JSON bodies are often left unparsed or misinterpreted as something else.

What's the difference between application/json and text/json?

text/json was an older, non-standard convention some systems used before application/json was formally registered. application/json is the correct, IANA-registered type and is what you should always use today.

Can application/json bodies include comments?

No — standard JSON doesn't support comments at all, unlike some supersets (like JSON5 or JSONC) that add comment support but aren't the same format and shouldn't be served as application/json.