The Request and Response Body

Every time you sign up for a website, post a comment, or load a page full of pictures, something is being shipped back and forth between your browser and a server. That “something” — the actual content, the data, the file — is what we call the body of an HTTP message. The headers describe the package, but the body is the package.

In this article you’ll get a clear, beginner-friendly picture of what the body is, when a request carries one, what a response sends back, and how a small header called Content-Type makes sure the receiver knows how to read it.

What the body actually is

Think of an HTTP message like a postal envelope. The envelope has an address, stamps, and notes written on the outside — that’s the request line and the headers. Inside the envelope is the letter itself — that’s the body.

The body is the payload: the real cargo. When your browser asks for a web page, the page’s HTML comes back in the body. When you submit a form, the values you typed get packed into the body and sent off. The body can be plain text, structured data like JSON, an image, a video, a PDF, or anything else.

+--------------------------------------+
| Request line:  POST /signup HTTP/1.1 |  <- what & where
| Headers:       Content-Type: ...     |  <- about the package
|                Content-Length: ...   |
|                                      |
| (blank line separates head from body)|
|                                      |
| Body:          { "name": "Jane" }    |  <- the payload itself
+--------------------------------------+

Notice the blank line. In an HTTP message, the headers come first, then one empty line, then the body. That empty line is how the receiver knows “the description is over, the actual content starts here.”

Request body: what you send to the server

A request body is the data your client (usually a browser, but it could be a mobile app or a script) sends to the server. You use it whenever you need to hand over information: a login form, a new blog post, an uploaded photo, a payment.

Here are the common shapes a request body takes:

• Form data — the classic format used when you submit an HTML <form>. Field names and values are joined together, like name=Jane+Doe&email=jane%40example.com.
• JSON — a clean, structured text format that most modern apps and APIs use. We’ll look at it closely below.
• A file upload — raw bytes of an image, document, or video, often sent in a special format called multipart/form-data that can bundle files and fields together.

Here’s what a request with a JSON body looks like end to end:

POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 54

{
  "name": "John Doe",
  "email": "john@example.com"
}

The first lines are the method and headers. Then the blank line. Then the body — the JSON object you’re sending to create a new user.

Response body: what the server sends back

A response body is the data the server sends back to your client after handling the request. This is the part you usually see or use: the web page, the search results, the picture, the download.

Response bodies come in many forms:

So the same idea — a body carrying a payload — covers everything from a humble web page to a giant video stream. Only the type of content changes.

   Browser                         Server
      |                               |
      |  ──── request (maybe body) ──>|
      |                               |  builds a response
      |  <── response (with body) ────|
      |                               |
   shows the page / uses the data

Which methods carry a body?

Not every request needs to send data. If you’re just asking for a page, there’s nothing to hand over. If you’re creating or changing something, you usually need to send the details.

GET is the odd one to remember: it asks for something and sends no body. Everything you need to pass with a GET goes into the URL itself (like ?page=2&sort=newest). POST, PUT, and PATCH, on the other hand, exist precisely to carry data, so a body is normal and expected.

Responses are different. Almost every response has a body — the page, the data, the error message. The main exceptions are responses that exist only to report a result, like a 204 No Content (success, nothing to return) or a response to a HEAD request (which asks for headers only, on purpose).

Content-Type: the label that says how to read it

A body is just a stream of bytes. Those same bytes could be text, an image, or compressed data — the receiver has no way to know unless you tell it. That’s the job of the Content-Type header.

Content-Type announces the format of the body so the other side knows how to interpret it. Some common values:

• text/html — treat it as a web page
• application/json — parse it as JSON data
• text/plain — plain text, nothing special
• image/jpeg — render it as a JPEG image
• application/x-www-form-urlencoded — classic HTML form data
• multipart/form-data — form data that can include file uploads

It works in both directions. When you send a body, you set Content-Type so the server reads it correctly. When the server replies, it sets Content-Type so your browser knows whether to draw a page, show an image, or trigger a download.

A closer look at JSON

JSON (JavaScript Object Notation) is the format you’ll meet most often in modern web development, so it’s worth a moment. Despite the name, it isn’t tied to JavaScript anymore — nearly every language reads and writes it.

JSON is just text, organized into key–value pairs. A key is a label in quotes; a value can be text, a number, true/false, a list, or another nested object.

{
  "id": 42,
  "name": "Jane Doe",
  "isActive": true,
  "roles": ["editor", "reviewer"],
  "address": {
    "city": "Jakarta",
    "country": "ID"
  }
}

Read it like a labelled form: name is “Jane Doe”, isActive is true, roles is a list of two items, and address is a small object tucked inside. This structure is exactly why JSON is popular — it’s human-readable and easy for programs to parse.

When this travels in an HTTP body, the message pairs it with Content-Type: application/json, and the receiver knows to parse the text into structured data rather than treat it as a plain string.

Putting it together

Let’s trace one complete round trip. Imagine an app at blog.acy-partner.com creating a new account:

POST /api/accounts HTTP/1.1
Host: blog.acy-partner.com
Content-Type: application/json

{ "name": "John Doe", "plan": "free" }

The server reads the JSON body, creates the account, and answers:

HTTP/1.1 201 Created
Content-Type: application/json

{ "id": 1009, "name": "John Doe", "status": "active" }

Both messages have a body. Both label it with Content-Type. The request body carries what to create; the response body carries what was created. Same mechanics, opposite directions.

Recap

The body is the heart of an HTTP message — the actual payload, separated from the headers by a single blank line. Here’s what to carry forward:

• The request body is data you send to the server (form data, JSON, file uploads). The response body is what the server sends back (HTML, JSON, images, files).
• Methods like POST, PUT, and PATCH normally carry a request body; GET does not — its data goes in the URL.
• Almost every response has a body, except deliberate empty ones like 204 No Content.
• Content-Type is the label that tells the receiver how to read the body. Get it right and everything just works.
• JSON is the everyday structured format: readable key–value text, paired with application/json.

Once the body makes sense, a natural next step is to look at status codes — the short numeric answers (like 200, 201, 404) that the server sends alongside the response body to say how the request went. Together, the status and the body tell the full story of every exchange on the web.