100 vs 103: Continue vs Early Hints
Both are 1xx informational responses sent before the final response, but they operate in opposite directions of the HTTP pipeline.
| Aspect | HTTP 100 — Continue | HTTP 103 — Early Hints |
|---|---|---|
| RFC | RFC 9110, Section 15.2.1 | RFC 8297 |
| Direction | Request pipeline — authorizes client to send body | Response pipeline — delivers resource hints before body |
| Trigger | Client sends Expect: 100-continue header | Server sends proactively while generating the response |
| Key header | None (empty body) | Link with preload/preconnect directives |
| Performance goal | Avoid sending a large body that will be rejected | Allow browser to prefetch subresources while server processes |
| HTTP/2 support | Not used (HTTP/2 streams handle this differently) | Yes — primary use case is HTTP/2 and HTTP/3 |
| Current status | Active | Active — gaining broad adoption |
100 Continue: Request Pipeline Authorization
100 Continue is part of the request pipeline. When a client wants to send a large body, it can first check whether the server will accept the request by sending headers only with Expect: 100-continue. The server either approves (100) or rejects (417 or another error). Only after receiving 100 does the client send the body.
This is entirely about efficiency in the request direction: don’t waste bandwidth sending a 500 MB file if the server is going to reject it because of a bad auth token or an invalid content type. 100 solves the request direction problem.
103 Early Hints: Response Pipeline Acceleration
103 Early Hints is part of the response pipeline. While the server is generating the final response (querying databases, rendering templates), it sends 103 ahead of time with Link headers telling the browser which resources it will need. The browser starts fetching those resources immediately, in parallel with the server’s processing.
HTTP/1.1 103 Early Hints
Link: </styles/main.css>; rel=preload; as=style
Link: </fonts/inter.woff2>; rel=preload; as=font; crossorigin
[server processes the request for 150ms]
HTTP/1.1 200 OK
Content-Type: text/html
...The browser receives the 103 and immediately starts fetching main.css and inter.woff2. By the time the 200 HTML arrives 150ms later, those resources may already be fully loaded, eliminating what would otherwise be serial fetches after HTML parsing.
Decision Rule
100 Continue is for request optimization: large body uploads, pre-validation of auth or content-type. Most HTTP clients and servers handle this automatically — you rarely need to implement it explicitly.
103 Early Hints is for response optimization: reducing page load time by preloading critical CSS, fonts, and JavaScript. Implement it on your web server or reverse proxy when server-side processing takes more than ~100ms and you know which subresources the page will need.
FAQ
Can I use both 100 and 103 in the same request/response cycle?
Theoretically yes — a client could send Expect: 100-continue, receive 100, send the body, and then receive 103 Early Hints before the final response. In practice this combination is extremely rare. 103 is typically used for browser page loads, which are GET requests that never use Expect: 100-continue.
Does 103 work with HTTP/1.1?
It can be sent over HTTP/1.1 but most HTTP/1.1 clients do not handle it correctly. 103 is designed for and most beneficial on HTTP/2 and HTTP/3 connections where browsers natively support it.
Is 100 needed in HTTP/2?
No. HTTP/2 streams are independent and can be reset individually. The body of a request is sent in stream DATA frames, and the server can reset the stream if it rejects the request. The Expect/Continue mechanism is specific to HTTP/1.1’s single-request-per-connection model.
Full Guides
HTTP 100 Continue — full guide · HTTP 103 Early Hints — full guide · All comparisons