---
title: "206 Partial Content"
canonical: "https://lemwatch.com/http-status-codes/206"
category: "success"
last_verified: "2026-08-11"
source: "https://lemwatch.com"
---

# HTTP 206 Partial Content

**TL;DR** — A 206 means the server sent only the chunk of a file you asked for — used for streaming video, resuming a download, or progressively loading a large file. It is normal and expected for media content. The fix-it list is empty unless your CDN or origin is returning 206 for things that should be a full 200 response.

## What it means

HTTP 206 Partial Content is a success response (it's not an error) that tells the client "here is the slice of the file you asked for." It is triggered when the request includes a Range header like Range: bytes=0-1023, asking for a specific byte range instead of the whole resource. The server replies with 206, a Content-Range header describing the slice that was returned, and just that slice in the body. This is how YouTube, Netflix, Spotify, and modern browsers stream video and audio without downloading the entire file upfront.

## Common causes

- <video> or <audio> element seeking inside a media file
- Resumable downloads (curl --continue-at, wget -c, browser download manager)
- PDF.js loading only the pages currently in view
- CDN edge serving large file slices in parallel
- Mobile app downloading large assets in chunks to survive a flaky network
- BitTorrent-style HTTP clients fetching segments of a large file

## How to fix

- A 206 on a media file or large download is correct — no action needed
- If a small HTML page or API endpoint returns 206 unexpectedly, check whether a misbehaving client is sending Range headers it shouldn't
- If videos won't seek in Safari or iOS, your server probably isn't honouring Range requests — enable byte-range support on Nginx (default), Apache (mod_dir + AcceptRanges), or your CDN
- For S3 / Cloudflare R2 / Backblaze B2, byte-range support is on by default — confirm your origin isn't stripping the Range or Accept-Ranges headers
- If a download client repeatedly re-fetches the whole file instead of resuming, your server is probably returning 200 instead of 206 — check the Accept-Ranges: bytes response header is present

## SEO impact

No direct SEO impact. 206 is a success response for byte-range requests on media files — Googlebot doesn't make range requests when crawling HTML, so you'll never see 206 on indexable pages. If your video sitemap pages serve media that needs to be played by Googlebot Video, byte-range support is required (Google can't index a video the player can't seek through).

## Monitoring tip

LemWatch reports the final status code on monitored URLs, so a healthy media endpoint will register as 200/206 depending on whether the check sent a Range header. We can also probe video endpoints with explicit Range requests to verify byte-range support is working — critical for sites that depend on video playback.

**Related:** [200](https://lemwatch.com/http-status-codes/200.md), [304](https://lemwatch.com/http-status-codes/304.md), [416](https://lemwatch.com/http-status-codes/416.md)

_Canonical HTML page: https://lemwatch.com/http-status-codes/206_