How to Send a JSON POST Request (With a Live Example)

Here’s the exact request this guide walks through — a POST to httpbin.org’s /anything endpoint, which accepts any method and body and echoes back exactly what it received. That makes it safe to send for real: no account, no side effects, nothing stored anywhere.

• POST https://httpbin.org/anything
• Content-Type: application/json
• {
• "name": "John Doe",
• "email": "john@example.com"
• }

POST https://httpbin.org/anythingContent-Type: application/json

Four things have to line up for this request to work: the method, the URL, the header, and the body.

• POST — tells the endpoint you’re submitting data, not just retrieving it. Most APIs use POST specifically for creating a new resource.
• URL (https://httpbin.org/anything) — the endpoint receiving the request. It echoes back anything sent to it, any method or body, which is what makes it useful for a guide like this one rather than a real API you’d need credentials for.
• Content-Type: application/json — tells the server the body is JSON rather than a query string or form fields, so it parses it correctly instead of guessing or rejecting it outright.
• Request body — the actual data being sent, as a JSON object. What keys and structure it needs to contain depends entirely on the API you’re calling; httpbin.org accepts anything.

This is the same request, built step by step in the API Request Builder:

• Open the API Request Builder.
• Select POST as the method.
• Enter https://httpbin.org/anything as the URL.
• Add a header: Content-Type set to application/json.
• Open the Body section.
• Select JSON as the body type.
• Enter the payload.
• Send the request.
• Inspect the response — status code, body, headers, and response time all appear once it comes back.

Once a request works, the same call can be copied straight out of the request’s code panel — no retyping it by hand:

• curl -X POST 'https://httpbin.org/anything' \
• --max-time 30 \
• -H 'Content-Type: application/json' \
• -d '{
• "name": "John Doe",
• "email": "john@example.com"
• }'

The same request as a fetch() call, ready to paste into frontend code:

• const controller = new AbortController();
• const timeoutId = setTimeout(() => controller.abort(), 30000);
• try {
• const response = await fetch("https://httpbin.org/anything", {
• method: "POST",
• headers: {
• "Content-Type": "application/json",
• },
• body: JSON.stringify({
• "name": "John Doe",
• "email": "john@example.com"
• }),
• credentials: "same-origin",
• signal: controller.signal,
• });
• const data = await response.text();
• console.log(data);
• } finally {
• clearTimeout(timeoutId);
• }

And the same request using the requests library:

• import requests
• json_body = {
• "name": "John Doe",
• "email": "john@example.com",
• }
• response = requests.post(
• "https://httpbin.org/anything",
• json=json_body,
• headers={
• "Content-Type": "application/json",
• },
• timeout=30,
• )
• print(response.status_code)
• print(response.text)

A handful of specific issues account for most "why isn’t my JSON POST working" reports.

• Missing Content-Type — send JSON without this header (or with the wrong value, like text/plain) and many servers won’t parse the body as JSON at all, even though the JSON itself is perfectly valid. The parsing fails before your data is ever looked at.
• Invalid JSON — a trailing comma, an unquoted key, or a stray quote breaks the whole body. {"name": "John Doe",} — a comma after the last field — is invalid JSON and will fail to parse, even though it looks almost right.
• Sending form data instead of JSON — application/x-www-form-urlencoded (key=value pairs joined with &) and application/json are different formats entirely. Setting the header to one while shaping the body like the other is a common way to get a confusing parse error.
• Wrong endpoint — a perfectly valid JSON POST to the wrong URL or path still fails; a 404 or routing error can look similar to a body-parsing error until you check the status code and response body.
• API expects a different schema — valid JSON only means the syntax is correct, not that the server accepts that particular shape. A missing required field or an unexpected key can still get rejected, even though nothing about the JSON itself is malformed.

JSON and form data are both common ways to send a body with POST, but they’re shaped differently and used for different things.

• JSON (Content-Type: application/json) — a structured payload of nested objects, arrays, numbers, and booleans. The default for most modern REST APIs.
• Form data (Content-Type: multipart/form-data) — flat key/value fields, and the only real option once a file is part of the payload; JSON has no native way to carry binary data.

Once the request is sent, four things are worth checking before assuming it worked: the status code first, then the body, the headers, and how long it took.

The status code alone tells you the outcome before you even read the body. 2xx generally means the request succeeded. 4xx means the problem is on the request side — bad input, invalid JSON, missing auth, a wrong URL. 5xx means the request reached the server fine but something failed while handling it.

The response body is worth checking too — httpbin.org echoes back exactly what it received, which is a fast way to confirm the server saw the same body you thought you sent. Response headers and response time round out the picture: Content-Type on the way back tells you how to parse the response, and response time is useful for spotting a slow endpoint before it becomes a production problem.

A request sent from a tool like this one, or from curl, isn’t subject to CORS — that restriction only applies to JavaScript running in a browser trying to read a cross-origin response. If this exact request works fine here but fails when called from your own frontend’s JavaScript, CORS is the most likely reason, not a problem with the JSON itself.