HTTP header inspection for practical use

HTTP headers are the compact metadata layer exchanged between a browser, application or API. They describe requests and responses, including status, caching, security policy, content negotiation and redirects. Inspecting them reveals whether the server behaves as intended, rather than merely whether the page appears to load.

Online HTTP header inspection tools make this metadata visible through a browser tab, command line or saved report. This guide explains what to inspect, how to interpret common fields and how Australian developers can compare results across fixed-line, mobile and remote test environments.

What an HTTP header inspection tool shows

Most inspection tools show the response status line and headers such as Content-Type, Cache-Control and Strict-Transport-Security. Some also display the request headers sent by the client, which matters when troubleshooting proxy authentication, CORS or content negotiation.

A response header is supplied by an origin or intermediary, while a request header describes what the client asked for. Tool-generated probes can differ from a real page load, so record the user agent, requested URL, method and test location before comparing two captures.

Choose the right inspection method

Chrome, Edge and Firefox DevTools expose these fields under Network. Select a request, open Headers and keep Disable cache enabled only for a controlled test; Copy as cURL preserves the request details for command-line replay.

For a quick GET without downloading the body, use curl -sS -D - -o /dev/null https://example.com. A HEAD request can return different headers, so repeat important checks with GET when redirect or caching behaviour is involved.

Hosted analysers are convenient for a public URL and often provide a quick security or redirect summary. When testing media, convert videos for testing and use a small clip, making Content-Type, Content-Length, Accept-Ranges and cache headers easier to compare.

Read security headers with context

Header names look technical, but their value depends on the whole response. Two groups form a practical baseline.

Security indicators include:

• Strict-Transport-Security instructs browsers to use HTTPS for future visits.
• Content-Security-Policy restricts which resources a page may load.
• X-Content-Type-Options: nosniff prevents MIME-type guessing.
• Referrer-Policy controls how much URL data travels with outbound links.

Performance and cache indicators include:

• Cache-Control sets when and where a response may be stored.
• ETag and Last-Modified support conditional requests.
• Content-Encoding identifies compression such as gzip or Brotli.
• Age shows how long a cached response has rested.

A header’s presence is not proof of correct implementation. A strict CSP may still allow a broad source list, while Cache-Control: public may expose personalised content if the application labels it incorrectly.

Trace redirects, cookies and cross-origin rules

Redirect chains appear as 301, 302, 307 or 308 responses with a Location header. Follow the chain, then inspect the final URL for leaked parameters, an unnecessary hop or a downgrade from HTTPS to HTTP.

Cookie behaviour is exposed through Set-Cookie. Check Secure, HttpOnly, SameSite, Domain and Path together; a Secure cookie can still be sent to an unintended subdomain if Domain is too broad.

CORS relies on headers such as Access-Control-Allow-Origin, Access-Control-Allow-Methods and Access-Control-Allow-Credentials. Browsers may first send an OPTIONS preflight, while command-line clients usually need the origin and request headers added manually.

Test the Australian path, not just your desk

Australia’s NBN is sold in speed tiers, but latency and routing can differ sharply between suburbs, fixed wireless, 5G and regional fixed-line services. Repeating a check from Sydney, Melbourne and Perth can expose an edge-cache or carrier issue that a single office test hides.

A local market check should include a .com.au domain, an Australian payment path and AUD prices with GST shown correctly. Headers cannot verify the final invoice, but they can reveal an overseas redirect, wrong content type or a bot-protection response during checkout.

Privacy matters here too. When diagnostic data includes personal information, the Privacy Act 1988 and guidance from the OAIC call for minimisation, so avoid pasting customer details, full query strings or personal identifiers into public inspection forms.

In Australian support conversations, “the server is having a bad day” is familiar shorthand. A captured response turns that phrase into evidence: it can separate an edge rejection from an origin failure or a local connection problem.

Capture results in a reusable format

Save a baseline as a HAR file or a plain text header dump, and include the timestamp, endpoint, method and test network. HAR files may contain cookies, authorisation values and response bodies, so redact them before sharing.

If a collector exports structured results as JSON, you can convert JSON to CSV before building a sanitised comparison sheet for a team. Keep the original capture private until credentials and personal fields are removed.

Compare status, redirect target, cache age, content length and security policy across runs. This turns a one-off observation into a repeatable record of regressions and third-party changes.

Build a safe, repeatable checking routine

Choose tools that use HTTPS, explain what they capture and offer local export where possible. Online inspection means a third party may fetch the target from its own server, exposing the URL, IP address and any embedded token to that service.

For teams, connect technical symptoms to service ownership, customer impact and revenue exposure through business context. This helps distinguish a harmless marketing redirect from a checkout failure that warrants urgent attention.

A durable routine checks critical endpoints after releases, compares them on an NBN connection and a mobile network, and stores sanitised evidence with the change record. It gives support staff a defensible answer when someone says the site is “falling over”, and it keeps technical evidence tied to customer impact.