{{ primaryRecommendation }}
| Field | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} | |
| No route summary available. | ||
| # | URL | Status | Method | Shift | Location | Time (ms) | Copy |
|---|---|---|---|---|---|---|---|
| {{ hop.index }} |
{{ hop.url }}
{{ hop.signalSummary }}
|
{{ hop.statusLabel }} |
{{ hop.method }}
{{ hop.methodNote }}
|
{{ hop.changeLabel }}
{{ hop.changeNote }}
|
{{ hop.location || '—' }}
{{ hop.resolvedLocation }}
|
{{ hop.time_ms }} | |
| No hops recorded. | |||||||
| Signal | Observed value |
|---|---|
| {{ row.label }} | {{ row.value }} |
| No route signals available. | |
No action notes were generated for this route.
{{ replayCommand }}
HTTP redirects are the response-level handoffs that move one URL to another. They are common during site moves, canonicalization, security upgrades, and short-link workflows, but the final destination can be hard to reason about when several hops are chained together.
This checker follows one URL hop by hop and reports the final destination, final status, redirect count, total elapsed time, and per-hop timing. It also shows whether the final response is using HTTPS and whether the final hop includes an HTTP Strict Transport Security, or HSTS, header.
That is useful when a link lands somewhere unexpected, when a page feels slower than it should, or when you need to prove exactly how a bare domain becomes a secure canonical URL. The package focuses on one address at a time and ignores extra lines, which keeps the result readable instead of pretending to be a bulk crawler.
It is important not to overread the result. A clean redirect chain does not prove that the final page is correct for every browser, user, or region, and the tool only follows HTTP redirects that have both a 3xx status code and a Location header. Meta refresh, JavaScript navigation, and browser-only behaviors are outside the scope of this package.
Privacy needs real caution here. The checked URL and current options are mirrored into the page address for shareable state, and the live request is sent to the bundled server helper so the chain can be observed from its network vantage point. Avoid pasting signed links, session tokens, password-reset URLs, or any other sensitive address into the form.
Most checks should start with the defaults: HEAD, 2500 milliseconds per hop, 10 maximum redirects, certificate validation on, and GET fallback on 405 enabled. That combination is fast enough for ordinary audits while still handling the common case where a server rejects HEAD but responds normally to GET.
Read the result in layers. The summary tab tells you where the request ended, how many redirects were followed, how long the trip took, and whether the final response advertises HSTS. The hop table then shows the exact URL, status, location header, and time for each step. The chart is there to expose timing concentration at a glance, especially when one slow redirect dominates the total.
Change the request method only when you have a reason. HEAD is lighter and often enough for redirect tracing. GET is the safer choice when a site behaves differently for full fetches or when you already know the server does not support HEAD. Likewise, turn certificate validation off only when you are deliberately investigating a broken HTTPS setup, because the resulting chain is no longer proof of a healthy secure path.
The limiting note deserves attention. If the summary shows timeout or max_redirects, the chain is incomplete by definition. In that situation, treat the visible hops as evidence of the partial path, not as a final answer about where the URL would eventually settle.
The package normalizes the input before tracing. If the address has no scheme, it prepends http://; if the resulting URL is not HTTP or HTTPS, the request is rejected before the helper is called. Only the first non-empty line is used, which means pasted lists are intentionally reduced to a single check.
The helper performs manual redirect tracing rather than letting the network stack follow redirects invisibly. Each hop records the URL that was requested, the numeric status code, the Location header if one is present, the elapsed time in whole milliseconds, and a short header subset for review. The surfaced headers are limited to location, strict-transport-security, content-type, server, cache-control, date, and vary.
Redirect following is strict. A hop only counts as a redirect when the status is in the 300 range and a Location header exists. If the location is relative, the helper resolves it against the current URL before continuing. If the location is malformed, the run stops with a bad_location error instead of guessing.
Method handling is also explicit. The helper starts with HEAD or GET based on your choice. If HEAD returns 405 and Fallback GET on 405 is enabled, the same hop is retried with GET and the chain continues in that mode. For redirect responses, the helper keeps the current method across 301, 302, 307, and 308, and switches to GET on 303.
| Control | Range or options | What it changes |
|---|---|---|
| Method preference | HEAD or GET | Changes the request method used for the first hop and for later hops unless the helper switches on 303 or 405 fallback. |
| Timeout (per hop, ms) | 200 to 4000 | Caps how long each hop can wait before the helper treats it as a timeout. |
| Max redirects | 1 to 20 | Limits how many redirect hops can be followed before the helper stops with a limit note. |
| Validate TLS certificate | On or off | Keeps invalid HTTPS certificates from being silently accepted when enabled. |
| Fallback GET on 405 | On or off | Retries a rejected HEAD request with GET when the server says the method is not allowed. |
| User-Agent | Optional text | Changes the identifier sent with the request, which can influence method-sensitive or bot-sensitive servers. |
Timing is bounded in two places. Each hop gets its own timeout, and the helper also stops when the remaining overall deadline is too small to continue safely. That is why a very slow chain can end with a timeout note even if the redirect count was still below your chosen ceiling.
The final summary is derived from the last recorded hop. Final URL and Final Status come from the end of the visible chain, Redirects counts only followed redirect hops, Time (ms) is rounded to whole milliseconds, and the HSTS badge is set only when the last response includes Strict-Transport-Security. A secure earlier hop does not carry that badge forward on its own.
The page exposes several export paths after the trace is complete. The summary table and hop table can be copied or exported as CSV and DOCX, the timing chart can be saved as PNG, WebP, JPEG, or CSV, and the JSON tab packages the normalized input, selected options, and the returned result in one structured snapshot.
Hop Details to confirm each Location header and identify where the chain changes host, path, or scheme.Chain Timeline when you need to see whether one hop is disproportionately slow.The summary row that matters most is Final URL paired with Final Status. A final 200 often means the chain resolved to a successful document fetch from the helper's point of view. A final 3xx means the chain ended before a non-redirect response was observed. A final 4xx or 5xx means the redirect logic may be correct but the destination still failed.
Redirects and Hops are related but not identical. Redirects count only followed redirect responses with usable locations. Hops count every recorded step, including the final non-redirect response. That distinction helps when you are explaining why a chain with two redirects can still show three hops in the table.
HTTPS tells you whether the final destination uses the secure scheme. The scheme badge at the top goes one step further by comparing the first and last URLs, so it can show a transition such as HTTP -> HTTPS. The HSTS badge is narrower still: it says only that the final response advertises a browser policy for future HTTPS-only use.
If the hop table shows a blank location on a 3xx response or a limit note appears in the summary, do not treat the chain as complete. Those are investigation clues, not clean handoff points.
A typical migration chain starts at http://example.test, returns a 301 to https://www.example.test, and then finishes with a 200 on that secure host. In the summary you would expect two hops, one redirect, an HTTP -> HTTPS scheme badge, and possibly an HSTS badge if the final response includes the header.
A method-sensitive case starts with HEAD and gets a 405 from the origin. With GET fallback enabled, the helper retries that hop with GET and may then continue through the rest of the chain normally. That is why a failed first attempt does not always mean the site is unreachable; it can mean the site objects to the lighter method.
A loop or excessively long chain shows up as a max_redirects limit note. The visible hops are still useful because they often reveal a repeating host or path pattern, but the summary is telling you the destination was not reached within the ceiling you set.
If the input has no scheme, the package prepends http:// before validation so the helper can trace a concrete HTTP request path.
No. It follows HTTP redirect responses with 3xx status codes and Location headers. Browser-side navigation after page load is outside the package scope.
The trace is executed by the bundled helper service, not by your local browser tab. Method choice, network path, geolocation, user agent, and certificate settings can all influence what the helper observes.
It only means the final response includes a Strict-Transport-Security header. It does not certify that every earlier hop was secure or that every client will behave identically.
No. The checked URL is sent to the server helper for live fetching, and the current input can also appear in the page address. Sensitive links should be tested with tools and procedures meant for private credentials.
Location header that the helper can follow.timeout or max_redirects indicating that the visible chain stopped before a clean finish.