Getting HTTP Status Codes and Headers with Screenshots
Inspect a request’s HTTP status and response headers in Chrome DevTools, then capture clear visual evidence with page-load context.

To see the HTTP status code and response headers for a specific request, use Chrome DevTools’ Network panel: reload the page, select the request, then open Headers. The request’s status appears under General; server response fields appear under Response Headers. To capture the page’s loading appearance alongside network activity, enable Network screenshots in Network Settings and reload. A screenshot documents what the browser showed; it does not replace the request details needed to establish the status and headers.
This guide covers the Chrome workflow, how to make the evidence legible, Firefox alternatives, command-line ways to record HTTP metadata, and common pitfalls. Browser tools report requests observed in that browser session, so first identify whether you need the document response, an API call, or an asset such as an image. See the official Chrome DevTools Network guide and its Network features reference.
1. Capture a request’s status and headers in Chrome
- Open the target page in Chrome and open DevTools. Select the Network panel.
- Reload the page while the panel is open. The request table records network requests from that load. If the request you need happened before DevTools was open, reload with the panel open to collect it again.
- Find the request you want. For the page’s own HTTP response, select its document request; do not assume the first listed row is the main page. A page may also make API requests and fetch scripts, fonts, and images, each with separate status and headers.
- Select the request, then open Headers in its details pane.
- Read the received status and human-readable status message in General. Read server-supplied fields in Response Headers. Request Headers describe what the browser sent and should not be presented as response headers.
- Capture the details with the request identity, status, and relevant header names and values readable. Include enough of DevTools to show that the evidence comes from the selected request.
The status applies to that individual request. For example, a page can have a successful document response while one image or API request fails. State the URL or request identity in your notes so someone reading the screenshot can tell which response it records.

2. Add screenshots tied to page-load timing
Chrome can record screenshots of the page during loading in the Network panel. Open Network Settings, enable Screenshots, and reload the page. The panel displays screenshot thumbnails; selecting one shows the network activity occurring at that point in the load. This is useful when the question is not only “what status did this request receive?” but also “what did the page look like as it loaded?” See Chrome’s instructions for capturing Network screenshots.

Keep two evidence goals distinct: a page-load thumbnail provides visual and timing context, while the selected request’s Headers view provides the status and response fields. If both cannot fit at readable size, save two screenshots. Label them with the target URL, request identity, and capture context; do not shrink the details until the header values are hard to read.
3. Make the evidence useful to another developer
- Identify the request: include the URL or enough of the request row to distinguish the document from API calls and assets.
- Show the correct fields: keep General and the relevant Response Headers visible. Avoid implying Request Headers came from the server.
- Preserve legibility: expand the relevant details pane and capture at a readable resolution. If the page and headers compete for space, use separate images.
- Record context: note the page URL and whether you captured a normal load or a particular loading state. Browser evidence represents the request observed in that session.
- Redact sensitive values: before sharing, inspect visible request and response fields for credentials, session identifiers, or other private data. Share only the information needed for the issue.
A screenshot is supporting evidence, not a complete network log. For a report that needs reproducibility, include the request URL, observed status, relevant header names and values, and a brief description of the browser context alongside the image.
4. Firefox: inspect the response and capture the page
Firefox is a browser-native option if it is already part of your workflow. Open Developer Tools and use the Network Monitor to select a request and inspect its details, including response status information. Firefox Developer Tools can also capture a full page or a selected element. Mozilla documents these separately in Network request details and Taking screenshots.
Use the Network Monitor for request evidence and the screenshot command for visual evidence. The sources document full-page and element captures, but do not establish that Firefox has the same Chrome Network screenshot timeline interaction described above. Choose based on the evidence you need rather than assuming those workflows are identical.
5. Record status and headers from the command line
When you need a text record as well as a screenshot, command-line clients can request response headers. These examples make a request to a URL you control or are authorized to inspect; replace the example URL. The screenshot is still a separate artifact unless you use a browser capture tool.
cURL
curl -sS -D response-headers.txt -o response-body.html https://example.com/
-D writes response headers to a file, while -o saves the response body. To print the status line and headers without saving the body, use:
curl -sS -D - -o /dev/null https://example.com/
Redirect behavior matters. By default, cURL reports the response to the requested URL and does not follow redirects. Add -L when you want to follow them; the output can then contain multiple response header blocks, so identify the final response rather than treating the first status as the destination’s result.
Python with Requests
import requests
url = "https://example.com/"
response = requests.get(url, timeout=30, allow_redirects=True)
print("Final URL:", response.url)
print("Status:", response.status_code)
for name, value in response.headers.items():
print(f"{name}: {value}")
with open("response-body.html", "wb") as output:
output.write(response.content)
Install the dependency with python -m pip install requests if it is not already present. With redirects enabled, Requests follows them and exposes the final response; inspect response.history if the redirect chain matters. A command-line response may differ from a browser request because the client, cookies, authentication, and request headers can differ.
Node.js built-in fetch
const url = 'https://example.com/';
const response = await fetch(url, { redirect: 'follow' });
console.log('Final URL:', response.url);
console.log('Status:', response.status);
for (const [name, value] of response.headers) {
console.log(`${name}: ${value}`);
}
const body = Buffer.from(await response.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('response-body.html', body));
Run this as an ES module or in a Node.js environment that supports global fetch. Fetch resolves for HTTP error statuses such as 404; check response.status or response.ok rather than assuming a rejected promise means every unsuccessful HTTP response.
6. Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. Its one-request API returns a screenshot or PDF, while its documented response headers identify the page verdict and billing result. For a rendered screenshot, use the call below; see the ScreenshotNeo API documentation for parameters and response details.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
timeout=90,
)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));
ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed; response headers say which result occurred. Its MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. A rendered screenshot does not itself expose the browser’s per-request Headers panel, so use DevTools or an HTTP client when the status and response headers are the evidence you need.
Create a free ScreenshotNeo account to get 1,000 screenshots a month with no card.
7. Troubleshooting
| What you see | Likely cause | What to do |
|---|---|---|
| The request is missing from the Network table | DevTools opened after it completed, or the page has not been reloaded. | Open Network before reloading and reproduce the request. |
| The status does not match the page you expected | You selected an API call, redirect, script, image, or other resource instead of the document request. | Check the request URL and type in the table; select the specific request relevant to the question. |
| A header appears under Request Headers | That is data the browser sent, not a response field supplied by the server. | Use Response Headers for server response fields and label request fields accurately. |
| The screenshot does not show the loading moment | Network screenshots were not enabled before the reload, or the relevant thumbnail was not selected. | Enable Screenshots in Network Settings, reload, then select the thumbnail associated with the desired point in the load. |
| Header values are too small to read | The page, request list, and details were squeezed into one capture. | Use separate labeled screenshots for page appearance and request details. |
| cURL output shows an unexpected status | A redirect may not have been followed, or the request differs from the browser session. | Use -L to follow redirects and inspect each status block; compare URL, cookies, and relevant request headers. |
| Python or Node.js reports a different result than Chrome | The clients may send different cookies or headers, or reach a different redirect destination. | Compare final URL, redirect history, credentials, and request context. A browser-session result is not necessarily reproduced by a bare HTTP client. |
| Node.js fetch does not throw for a 404 | HTTP error status responses still resolve as responses. | Check response.ok or response.status explicitly. |
8. Performance, reliability, and cost
For a one-off check, the browser workflow avoids writing a script and preserves the session context. For repeated checks, command-line clients are easier to automate, but they record HTTP responses without reproducing browser rendering and may not share the browser’s cookies or request behavior. Browser screenshots and network details should be captured from the same reproduction when their relationship matters.
Keep evidence reliable by recording the exact target and request, capturing after the request has appeared, and separating visual context from detailed fields when needed. A screenshot can establish what was visible in the tool at capture time; it cannot establish that another session, region, or later request will produce the same response. No benchmark or fixed cost applies to Chrome or Firefox’s built-in workflows in the cited documentation. ScreenshotNeo’s stated plans are Free with 1,000 shots/month, Starter $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000; yearly billing gives two months free, and every feature is on every plan.
FAQ
Does a screenshot prove the HTTP status?
It can show the status displayed in the selected request’s details, but preserve the request identity and readable fields so the evidence is interpretable. A page image alone does not show response headers.
Should I capture the document or an API request?
Capture the request whose result you are documenting. Use the document request for the page response and the specific API request when investigating application data.
Can an image screenshot include every header?
Only if the relevant fields fit legibly in the capture. If not, use multiple labeled captures or save a text header record with cURL, Python, or Node.js.
Can I use Firefox instead of Chrome?
Yes. Firefox’s Network Monitor exposes request details and Developer Tools supports full-page or element screenshots. Use Chrome’s documented Network screenshot workflow when you specifically need the screenshot timeline tied to network activity.


