{ }HttpStatus.com

103 Early Hints

Interim response that lets the server send preload or preconnect hints to the client before the final response is ready.

Defined in RFC 8297 §2

What 103 means

HTTP 103 Early Hints allows a server to send some response headers, typically Link headers for preload, preconnect, or dns-prefetch, before it has finished computing the actual response. This is valuable when the final response depends on slow backend work such as a database query or an origin fetch, but the resources the page will need, its stylesheets, fonts, and key scripts, are already known in advance. The browser can start fetching those resources immediately while the server is still assembling the real HTML.

A typical flow has a CDN or edge server hold the connection open, immediately return 103 with Link headers pointing at critical assets, then forward the request to a slower origin, and once the origin replies, send the final 200 (or other) response with its own headers. Because a client might receive zero, one, or multiple 103 responses before the final one, and the final response can repeat or override any header sent early, clients must merge hint headers rather than assume the early ones are authoritative.

Support has grown steadily among CDNs, edge platforms, and modern browsers, which use the Link preload hints to warm up connections and fetch render-blocking assets in parallel with origin processing. It has the most impact on pages with a slow time-to-first-byte, since the browser can start downloading CSS and fonts during that dead time rather than after. Servers that do not support 103 simply skip it, so adding it is a safe, incremental performance optimization.

Common causes

  • The origin server or edge platform supports early hints and knows in advance which assets the eventual page will request.
  • The final response depends on a slow backend operation, such as a database call, that delays the real headers.
  • A CDN is configured to synthesize 103 responses with Link preload headers ahead of a slower origin fetch.
  • The application explicitly calls an early-hints API in its framework before finishing request processing.

How to fix a 103

If you are the client (browser user or API caller)

  • Use a browser or HTTP client that understands 103 and starts preloading the linked resources immediately rather than waiting for the final response.
  • Merge headers from any 103 responses with the final response's headers instead of discarding the early ones.
  • Do not treat 103 as final; keep the connection open and wait for the real status code.

If you run the server

  • Send Link preload or preconnect headers for assets you can identify before slow backend work completes, then follow with the final response.
  • Only hint resources that are actually needed for the page to avoid wasting client bandwidth on speculative fetches.
  • Verify the reverse proxy, CDN, or load balancer in the path forwards 1xx responses instead of buffering them until the final response is ready.
  • Keep early hint headers consistent with what the final response ultimately sends to avoid confusing caches or clients.

Example

GET /articles/http-status-codes HTTP/1.1
Host: example.com

HTTP/1.1 103 Early Hints
Link: </styles/main.css>; rel=preload; as=style
Link: </fonts/sans.woff2>; rel=preload; as=font; crossorigin

HTTP/1.1 200 OK
Content-Type: text/html
Link: </styles/main.css>; rel=preload; as=style
...
Edge server hints critical assets while the origin is still generating the page.

Try it live

Our free status responder returns a real HTTP 103 you can point tests, monitors or a browser at.

GET https://mcp.httpstatus.com/status/103

Related status codes

Tools for debugging this