HTTP 103 EARLY HINTS

Preliminary Link headers so the browser can preload assets while the final response is prepared. 103 belongs to the 1xx informational class and is defined in RFC 8297.

Zero retention: your headers never leave this browser. Verify it yourself in DevTools.

Loading the workbench.

About HTTP 103

What Does HTTP 103 Early Hints Mean?

Preliminary Link headers so the browser can preload assets while the final response is prepared. The code is registered with IANA and defined in RFC 8297.

Informational: the request was received and the process continues. Every code from 100 to 199 shares that general meaning, so a client that does not recognise 103 must treat it like 100.

When Do You See a 103 Response?

103 Early Hints lets a server tell the browser about critical subresources before the final response is ready. While the application is still querying a database, the server or CDN sends a 103 carrying Link headers with rel=preload or rel=preconnect, and the browser starts fetching stylesheets, fonts, or connecting to origins in parallel. Chrome, Edge, Firefox, and Safari support it over HTTP/2 and HTTP/3, and several CDNs can generate it from cached Link headers.

How Do You Handle a 103?

Send only hints that are safe for every possible final response, because the browser acts on them before it knows whether the page will be a 200 or a 500. Put the same Link headers on the final response too. Browsers ignore 103 over HTTP/1.1 in practice, and some old proxies mishandle interim responses, so test through your real edge. Clients that do not understand 103 simply discard it.

What Does a 103 Response Look Like?

HTTP/1.1 103 Early Hints
Link: </styles/main.css>; rel=preload; as=style
Link: <https://fonts.example.com>; rel=preconnect

103 is not cacheable by default: a browser or CDN stores it only when Cache-Control or Expires explicitly allows it.

To inspect a real one without sending it anywhere:

  1. Copy the response headers from your browser Network tab, or from curl -i.
  2. Paste them into the Header decoder to see every header explained.
  3. Check caching in the Cache lane.

Which Status Codes Are Related to 103?

  • 100 Continue: The headers were fine; send the body. Used with Expect: 100-continue so a client does not upload a large body that would be rejected.
  • 200 OK: The request succeeded. The body depends on the method.
  • 102 Processing: WebDAV: the server is still working on a long request. Deprecated in practice.

Browse every code on the HTTP status codes page.

What Other Lanes Are in the Reference Section?

  • HTTP status codes: Every IANA-registered status code, with a page per code.
  • MIME types: File extensions to Content-Type, searchable both ways, plus a Content-Type parser.
  • HTTP methods: GET, POST, PUT, PATCH, DELETE and the rest: safe, idempotent, cacheable.

Elsewhere in 2http: Header decoder, Cookie decoder, Cache-Control decoder, CORS checker, User-agent parser, and all eleven lanes on the 2http home page. Part of the 2suite.io privacy-first ecosystem.

Frequently Asked Questions

Does 103 Early Hints replace the final response?

No. It is an interim response. The real status, such as 200, always follows on the same request, and it should repeat the Link headers so caches and older clients see them.

Can I put cookies or security headers in a 103?

Browsers ignore most headers on a 103 apart from Link and a few policy headers. Set cookies, caching, and security headers on the final response, where they actually take effect.

Is HTTP 103 an error?

No. 103 is a informational response, not an error.

Is a 103 response cacheable by default?

No. Caches store a 103 only when Cache-Control or Expires explicitly allows it.

How Can You Verify That Nothing Leaves This Browser?

You do not have to take our word that your headers stay here. Developer tools show every request a page makes, so you can watch this page work and confirm that nothing is sent. The check takes under a minute.

  1. Open your browser developer tools with F12, or Cmd+Option+I on a Mac, and select the Network tab.
  2. Reload the page and let it finish. You will see the page's own files, its web fonts, and one anonymous page-view request. Nothing has been typed yet, so none of them can contain your headers.
  3. Click the clear icon in the Network tab so that the log is empty.
  4. Paste real headers into any lane and read the result.
  5. Look at the Network tab again. It is still empty. For extra proof, turn on offline mode after the page loads and every lane keeps working.

Only two things can add a line to that log, and neither carries your headers. Submitting the feedback form sends the vote and comment you typed. Typing characters in a script the page has not displayed yet, such as Cyrillic or Greek, can make the browser fetch the matching font file, and that request names only the font.

2http never sends a request on your behalf: the request builder writes code for you to run, and the meta inspector reads source you paste instead of fetching a URL. The production site also sends a Content-Security-Policy header that tells your browser to refuse connections to anywhere except this site and the anonymous analytics endpoint.

Was this helpful?