Byte Range Requests: HTTP Partial Content Explained

What Is a Byte Range Request?

Without byte range requests, downloading any file was all-or-nothing. Your browser had to receive every byte of a file before it could do anything with it. For a 500 MB PDF or a 4 GB video, that meant waiting — or failing entirely on slow connections.

Byte range requests changed that. Defined in RFC 7233 as part of HTTP/1.1, they give browsers a way to ask servers for a precise slice of a file. Think of it like using a bookmark: instead of re-reading an entire book, you open to exactly the page you need.

The protocol works through two HTTP headers working together. The client sends a Range header specifying which bytes it wants. If the server supports it, it advertises that capability with Accept-Ranges: bytes and responds to range requests with HTTP 206 Partial Content — a specific status code that means "here's the portion you asked for."

Byte ranges are measured in octets (bytes), zero-indexed from the start of the file. So bytes=0-499 means the first 500 bytes. bytes=-500 means the last 500. bytes=1000- means everything from byte 1000 to the end.

How Byte Range Requests Work

The process follows a clear handshake between browser and server:

1. Browser checks for range support. On an initial request, the server includes Accept-Ranges: bytes in its response headers. This signals that the server can handle partial requests. If the header is absent or says none, partial fetching is not supported.
2. Browser sends a range request. The browser adds a Range header to its next request, specifying a byte range — for example, the data needed for page 12 of a PDF, or the next chunk of a video stream.
3. Server returns 206 Partial Content. The server sends back only the requested bytes, along with a Content-Range header telling the client exactly which slice was returned and the total file size.
4. Browser assembles the data. The browser uses the returned bytes and may issue additional range requests as needed — for example, when the user scrolls to a new page or seeks to a different position in a video.

The Request / Response in Practice

Here's what the actual HTTP headers look like:

GET /documents/manual.pdf HTTP/1.1
Host:       example.com
Range:      bytes=500-999
# Requesting bytes 500 through 999 (500 bytes total)

HTTP/1.1 206 Partial Content
Content-Range:  bytes 500-999/26012
Content-Length: 500
Content-Type:   application/pdf
Accept-Ranges:  bytes
# Server sends exactly 500 bytes; total file is 26,012 bytes

Real-World Examples

Technical Breakdown

Here's a quick reference for the key headers and status codes involved:

What Is HTTP 206 Partial Content?

HTTP 206 Partial Content is the success status code for a byte range request. It tells the browser: "I received your range request, it was valid, and here are the exact bytes you asked for." A 206 response always includes a Content-Range header so the client knows exactly where the returned data fits within the full file.

A regular 200 OK response means the full file was sent — either because the server does not support ranges, or because no Range header was sent. If you see 206, partial content delivery is working correctly.

Byte Range Requests and PDF Linearization

For byte range requests to fully deliver their benefit in PDFs, the document needs to be linearized (also called "optimized for Fast Web View"). A linearized PDF places the most critical data — the document catalog and the first page — at the very beginning of the file. This means the browser can issue a single small range request and render the first page immediately, without knowing anything about the rest of the file. Additional pages are fetched as the user scrolls.

A non-linearized PDF may have its cross-reference table scattered throughout. Even with byte range support, the browser may need multiple round trips to locate necessary data, reducing the speed advantage.

Benefits of Byte Range Requests

Common Mistakes to Avoid

• Uploading non-linearized PDFs. Byte range requests work, but without linearization the first page still may require multiple round-trips to load. Always optimize PDFs for Fast Web View before hosting them.
• Disabling range support on your server. Some CDN configurations or custom server middleware inadvertently strips the Accept-Ranges header. Check your response headers to confirm range support is active.
• Ignoring the Content-Range header in your app. If you are building a custom file viewer or download client, you must read the Content-Range header to correctly place the received bytes in your buffer.
• Using multi-range requests without testing browser support. HTTP allows requesting multiple disjoint ranges in a single request. However, not all clients and servers handle multipart responses consistently. Test thoroughly before relying on this in production.
• Assuming 206 means the full file was delivered. A 206 response always means partial delivery. If your code treats it like a 200, you will end up with incomplete data.

Frequently Asked Questions

• What is a byte range request?

  A byte range request is an HTTP request that includes a Range header specifying which bytes of a file the client wants. Instead of sending the entire file, the server responds with HTTP 206 Partial Content and delivers only the requested portion. This is the foundation of video streaming, resumable downloads, and fast PDF rendering.

• What HTTP status code does a byte range request return?

  A successful byte range request returns HTTP 206 Partial Content. If the server doesn't support ranges, it returns a normal 200 OK with the full file. If the requested range falls outside the file size, it returns 416 Range Not Satisfiable.

• How does a browser make a byte range request?

  The browser adds a Range header to the HTTP request — for example, Range: bytes=0-1023. The server must first signal support by responding with Accept-Ranges: bytes on an initial request. If that header is present, the browser knows it can send range requests for future fetches from that server.

• Why are byte range requests important for PDFs?

  Large PDFs can be several hundred megabytes. Without byte range requests, a browser would download the entire file before showing any page. With byte range requests — paired with a linearized PDF — the browser fetches just the first page's data (often under 100 KB) and renders it instantly. Additional pages are requested only as the user navigates to them.

• What is the difference between HTTP 200 and 206?

  HTTP 200 OK means the full file is being delivered — no range was requested or the server sent the whole file anyway. HTTP 206 Partial Content means the server is responding to a specific range request and sending only the bytes that were asked for. The Content-Range header in a 206 response shows exactly which slice was returned.

• Do all web servers support byte range requests?

  Most modern servers — Apache, Nginx, Caddy, IIS, and cloud storage providers like AWS S3 and Google Cloud Storage — support byte range requests by default. Some older, custom, or restrictive servers may not. You can verify support by checking whether the response includes Accept-Ranges: bytes. If it says Accept-Ranges: none or is missing, range requests won't work on that server.

Related Glossary Terms