MyIP.dogChecking…
HTTP headers check
Inspect response headers and redirects, with probe locations and TLS verification results.
Checking…
Inspect response headers and redirects, with probe locations and TLS verification results.
Checking…
Checking…
Globalping receives the URL and publishes targets and results. Submit public pages only, without passwords, tokens or personal information.
HTTP headers check limits: up to 5 responses, HEAD requests only, 55-second collection deadline. No browser cookies or authorization headers are forwarded.
Ready for an HTTP headers check.
An HTTP headers check helps answer a practical question: what did a web server return before the page content? Enter a public URL, choose IPv4 or IPv6, and start the check. The result shows response fields, status codes, redirect steps, the selected public address, and the remote probe that made each request.
This HTTP headers check uses HEAD requests. It collects metadata without asking the probe to download a page body. A normal browser visit usually uses GET, so compare results with that distinction in mind. The method is fixed and visible; the tool does not silently switch to GET when a website rejects HEAD.
Before running an HTTP headers check, remove passwords, access tokens, email addresses and private identifiers from the URL. Globalping receives the submitted target, path and query, and makes measurement results public. The destination receives a request from a remote probe. Google Public DNS receives hostname resolution queries through our server.
For a first HTTP headers check, select Use example, then Check HTTP headers. The example fills https://example.com; it does not start network traffic by itself. You can replace it with a public page on your own website. Include a specific path when that is the response you want to inspect.
The HTTP headers check assumes HTTPS when you omit the scheme. It accepts ordinary HTTP on port 80 and HTTPS on port 443. Other ports, embedded login credentials, local addresses and unsupported protocols are rejected. A URL fragment, such as #pricing, is removed because it is not sent in an HTTP request.
An IPv4 HTTP headers check resolves A records and selects one supported public address. IPv6 uses AAAA records instead. A domain can produce different responses across those families because its routing or deployment differs. A failed IPv6 measurement does not establish that your own browser lacks IPv6: the request comes from a remote probe.
For hostnames, this HTTP headers check fixes the selected address before submitting the probe request. It preserves the requested hostname for Host and TLS SNI. Redirect destinations go through the same validation and resolution process. The result identifies the chosen address; it does not pretend that one address represents every server behind a domain.
Begin with the HTTP status code and the URL for each step. In an HTTP headers check, a 200 means that this particular request received a successful response. A 404 is also useful evidence: the server answered, but the requested resource was not found. Neither code establishes the quality of the website as a whole.
A completed HTTP headers check can contain a 403 or 405. The first may reflect an access policy; the second indicates that the method is not allowed for that resource. Those are actual responses, not transport failures. Investigate their values and compare with the website's intended behavior before changing a server configuration.
The HTTP headers check follows supported redirect responses—301, 302, 303, 307 and 308—when there is one usable Location value and the next destination passes validation. A relative Location is resolved against the current URL. The tool stops on loops, ambiguous locations, unsupported destinations, incomplete responses or the five-response limit.
For example, an HTTP headers check may show http://example.com/ redirecting to its HTTPS URL, followed by a final 200. Read the fields on both steps. A policy on a redirect response is not automatically the policy on the final document. This is especially relevant when a CDN, application and separate login service manage different parts of a journey.
Each step in the HTTP headers check includes its probe city, country, network, ASN and update time. Steps may use different Globalping probes. Treat the chain as a sequence of individually observed responses, not a single persistent browser session. Geographic routing, server changes or access controls can affect which result each probe sees.
The header review in this HTTP headers check uses three states. Present means a named field was returned. Absent applies to a complete response in which that field was not found. Not tested or incomplete means there is insufficient evidence to call it absent. The review does not validate every directive or simulate browser enforcement.
A security headers checker should explain its evidence rather than award a reassuring grade from a field count. This HTTP headers check deliberately shows the actual values beside a limited presence review. A field can exist with an ineffective, malformed or unsuitable value. A missing field may also be irrelevant to a non-document response.
Use the HTTP headers check to inspect Content-Security-Policy, then review the directives against the site's resources and threat model. A policy field is not proof that scripts are safely constrained. The report-only variant has a different purpose and must not be confused with enforcement. MDN's CSP reference explains the directive model.
For Strict-Transport-Security, the HTTP headers check shows the received value and the scheme on that step. HSTS tells supporting browsers about future HTTPS use; it is not a substitute for checking the certificate on the current connection. Review duration and subdomain scope in the HSTS documentation before changing a deployment.
Other useful fields in an HTTP headers check include X-Content-Type-Options, Referrer-Policy, Permissions-Policy and X-Frame-Options. They address different browser behaviors. Use the OWASP Secure Headers project as a starting point for a configuration review, then test your own application. Copying an unrelated site's policy can break legitimate functionality.
The HTTP headers check also makes Cache-Control and Content-Type easy to find. A page intended to show visitor-specific information needs different cache behavior from a versioned public image. Compare the observed values with the resource's intended use. A single response cannot prove how every intermediary or browser will handle future requests.
This HTTP headers check displays the TLS authorization result reported by the probe. Globalping can collect headers even when its certificate verification does not succeed. Such headers are shown as observations from an unverified connection, and this tool stops before following another redirect. It does not label that result a trusted HTTPS response.
An authorized TLS result in the HTTP headers check applies to the probe's connection and trust environment at that moment. It is not an exhaustive certificate audit. This tool does not inspect every possible chain, revocation path, supported cipher or browser trust store, and it does not certify an entire website as safe to visit.
An HTTP headers check has a collection deadline of 55 seconds and a maximum of five measured responses. Each submitted probe has a ten-second measurement timeout. Network delays, service availability and rate limits can prevent a complete chain. When the limit is reached, the last redirect may be visible even though its destination was not requested.
The HTTP headers check preserves collected steps when a later lookup or provider request fails. Inspect the stopping reason before interpreting the chain. An empty or partial result is not evidence that all security headers are missing. Retry after checking the hostname, address family and public availability, rather than repeatedly submitting the same failing request.
Some servers return long fields or many cookies. The HTTP headers check marks a shortened provider response and stops further redirects, because truncated evidence may omit or alter an important field. Review the public source measurement where appropriate, but do not assume it contains data the probe itself never retained. Header values are displayed as text.
The HTTP headers check forwards neither your browser cookies nor its authorization headers to the destination. It does not log in, solve a challenge or execute a page's JavaScript. Consequently, authenticated pages and bot-sensitive endpoints may differ from what you see in a normal tab. The tool is intended for public response diagnostics.
Stop collection ends this page's wait, but an HTTP headers check already submitted to Globalping may still finish there. Clearing the form removes local inputs and displayed results; it does not retract a public measurement. Do not use this tool for private URLs. Copied reports contain the submitted URLs and response values, so review them before sharing.
Repeated requests are bounded by per-visitor and runtime-local limits. An HTTP headers check can also encounter Globalping's own allowance limits. These controls are not a promise of unlimited capacity or a deployment-wide service guarantee. Wait when a quota message appears. A rate-limit response is different from an HTTP error returned by the tested website.
If an HTTP headers check stops before receiving a response, start with hostname lookup to inspect public A, AAAA and CNAME records. Use DNS lookup when you need a particular record type. Those tools explain DNS evidence; they do not replace the actual HTTP request needed to observe response headers.
After a successful HTTP headers check, compare the exact path with a browser's Network panel if users still report a problem. Check whether the method, cookies, region or cache state differs. For routing questions, ping testing and traceroute add different observations. Their replies cannot prove an application is serving the correct content.
It requests headers with HEAD and does not intentionally request a response body. A server can implement HEAD differently from GET or reject it altogether. The HTTP semantics standard defines that method; the result here records the response actually observed, including a method rejection.
The selected public address, probe location and time can change. Load balancing, staged deployments and regional policies can produce legitimate differences. Compare the recorded source details before treating a changed field as a regression. For a repeatable deployment test, also use a controlled client with an explicitly chosen destination and request configuration.
No. This request originates from a remote Globalping probe, not through your browser's VPN tunnel. Use IP comparison to compare browser-visible exits, and understand each separate test's limitations. Response fields describe a website's reply to the probe; they do not establish whether your own traffic is protected.
Keep the URL, method, address family, selected address, probe identity, timestamps and relevant field values together. The copy action includes this context and links to the public source measurements. Describe incomplete steps explicitly when reporting a problem. A screenshot of one header without its request context can lead to the wrong diagnosis.
Implementation and source behavior were checked on September 28, 2026. Probe transport details are documented in the Globalping HTTP implementation; provider limits and measurement access are described in the Globalping API reference. The HTTP headers check uses those observations within the narrower limits stated above.