Get Response Headers in JavaScript with Fetch and XHR

Read headers from the response object

In browser JavaScript, response headers belong to the Response returned by fetch. Read one value with response.headers.get or enumerate the exposed entries. This is different from the headers supplied in the request options, and it does not provide an unrestricted capture of every field sent over the network.

async function responseHeaderSummary(url, fetcher = fetch) {
  const response = await fetcher(url);
  return {
    status: response.status,
    contentType: response.headers.get("content-type"),
    requestId: response.headers.get("x-request-id"),
    entries: [...response.headers.entries()]
  };
}

The helper preserves the HTTP status even for a readable error response. A missing or unavailable header is represented by null, not an invented empty value. Header names are case-insensitive, so requesting Content-Type should identify the same field as content-type.

This helper intentionally returns only a header summary. It does not consume, return or render the response body. If the application also needs that body, perform the required parsing in the same function or return the response through a documented interface. Do not issue a second request merely to obtain content that was already available with the first response.

Reading header entries does not consume the body stream, but reading the body normally does. Plan whether the caller needs text, JSON or a Blob before calling those methods. If two consumers truly need independent reads, use an appropriate clone before consumption and consider the memory impact for large responses.

Inspect an existing XMLHttpRequest flow

function xhrHeaderSummary(url) {
  return new Promise((resolve, reject) => {
    const xhr = new XMLHttpRequest();
    xhr.open("GET", url);
    xhr.timeout = 5000;
    xhr.onload = () => resolve({
      status: xhr.status,
      contentType: xhr.getResponseHeader("Content-Type"),
      requestId: xhr.getResponseHeader("X-Request-ID"),
      raw: xhr.getAllResponseHeaders()
    });
    xhr.onerror = () => reject(new Error("Network request failed."));
    xhr.ontimeout = () => reject(new Error("Request timed out."));
    xhr.onabort = () => reject(new Error("Request aborted."));
    xhr.send();
  });
}

For an application already using XHR, this records the values after the request loads. Its timeout is an example policy, not a universal ideal. A 404 or 500 can still reach onload because an HTTP response arrived; inspect status before applying the application's success behavior.

The getAllResponseHeaders documentation describes the returned string and excluded fields. Treat this string as the browser's exposed header view. It is not a reason to remove the browser's access restrictions or expose private server diagnostics.

Explain a value that appears in DevTools but is null in code

A cross-origin response may be visible in the network panel while JavaScript is permitted to read only some of its headers. If the application needs a custom response field, the service must expose it through its CORS response policy where appropriate.

For a local example, let one fixture return X-Request-ID: fixture-a without exposing it and another explicitly expose X-Request-ID. Fetch and XHR should show the custom value only in the permitted case. Changing the JavaScript header name's capitalization does not fix an exposure problem.

The exposure-header reference distinguishes this policy from permission to send request headers. Set-Cookie is a further boundary: naming it in an exposure list does not make it readable to front-end scripts.

Avoid turning header text into executable markup

When displaying a returned value, assign textContent or use the framework's ordinary escaped text binding. A diagnostic header can contain untrusted text. It should not become HTML merely because a debugging screen labels it as server metadata.

Also limit and redact diagnostic storage. Request identifiers may be useful for correlating one failure, but copying every header and body into analytics can retain unnecessary private data. Store the fields required for the investigation under the application's logging policy.

Label a failed read explicitly instead of showing an older header summary as current.

Test availability and a subsequent response

Test both helpers against controlled same-origin and cross-origin responses. Include a custom field, a missing field and an HTTP error. Change the request identifier on the second response and verify that the UI updates rather than keeping a previously displayed value.

The Response Header Checker can review pasted header text after capture. It does not run either helper or bypass CORS. Use the browser examples to collect the available values, then keep the checker result separate from any claim about fields the browser did not expose.

Related guides

REST Response Headers: Follow Pagination Links Deliberately

Read pagination links in a REST response, resolve relative targets against its URL, and prevent loops, off-origin credential forwarding, and lost items.

Cloudflare Response Headers

A practical guide to cloudflare response headers, including the key steps and checks for syntax, semantics, input data and environment-specific output.

Python Requests Get Response Headers

Solve python requests get response headers with a focused url http & curl workflow and final checks for syntax, semantics.