A URL that looks fine in the address bar can take three or four hops before it lands somewhere. Each hop adds latency, each hop is a potential point of failure, and any one of them can quietly strip cookies, downgrade the scheme, or send a referrer to a domain the marketing team didn’t expect. The browser hides all of that by default — by the time you see the page, the chain has already collapsed into a single URL. The PortJar Redirect Tracer makes the chain visible so you can decide what to keep and what to remove.
What the tool does
Redirect Tracer fetches the URL you give it and follows every 3xx response in sequence, returning the full hop list — request URL, status code, the Location header that triggered the next hop, and the final destination. It will not render the page, will not run JavaScript, and will not silently collapse the chain the way a browser does. The output is what a fresh HTTP client sees on the first request, before any cookies or service workers get involved.
The result is shareable through a stateless URL — paste the trace into a ticket and the next person sees the same chain when they reload it. That matters when a chain only happens for a specific URL, locale, or campaign parameter and you need to prove it without reproducing the original conditions.
How to use it
Open portjar.com/tools/redirect-tracer, paste the full URL including the scheme and any query parameters, and run. The hop list shows up immediately. Read top to bottom — the first row is what you typed, the last row is where the request finally settled, and every row in between is something that rewrote the destination along the way.
When you’d reach for it
- Catching unwanted vendor or shortener hops. Marketing handed you a campaign URL that goes through a tracking domain you didn’t authorise. The trace shows the hop, lets you screenshot it for the vendor conversation, and gives you the canonical destination you should actually publish.
- Diagnosing a broken canonical pair. A
wwwhost that 301s to apex, where the apex 302s back towww, produces a redirect loop the browser will eventually break with an error page. The tracer flags the loop in two seconds. - Verifying scheme upgrades. Every public URL should land on HTTPS after at most one hop. If the trace shows
http://example.com→http://www.example.com→https://www.example.com, the first hop is unnecessary and is leaking traffic in cleartext. - Auditing a migrated site after a cutover. When you move a site to a new platform, you want every old URL to land on the right new one with a 301, not a 302 or a 404. Spot-check a handful of high-traffic URLs through the tracer to confirm.
- Confirming a vanity domain or partner subdomain still points where it should. Vendors rotate URLs more often than their customers notice. The tracer is the fastest way to confirm a vanity URL still terminates on your origin and not on a parked domain.
What to make of the output
A clean trace is one or two hops ending in a 200. Anything longer deserves a second look — chains compound latency, and on a slow connection a four-hop redirect can cost a full second before the first byte of content. If the chain is long but legitimate, document why so the next engineer doesn’t try to “clean it up.”
Watch the status codes. A 301 (permanent) tells downstream caches and search engines to remember the new location. A 302 or 307 (temporary) tells them not to. Using 302 where 301 was meant is a common mistake on cutovers and is invisible until traffic data goes sideways. The tracer puts the exact status code in front of you on every hop.
Watch the scheme transitions. Any hop in plain HTTP is a hop in cleartext — cookies on those hops are exposed, and depending on the cookie’s Secure flag, may not be sent on the next hop either. If a public-facing chain has even one HTTP hop, fix it.
Watch for cross-domain hops. A redirect from your domain to a vendor domain and back is a moment where the user’s referrer leaks, and where cookies don’t survive. Sometimes that’s intentional (SSO flows). Sometimes it’s a tracker the marketing tool added by default.
If the trace lands on a 4xx or 5xx, you have your bug — the previous hop is sending traffic to a destination that no longer answers. Pair the result with the HTTP Headers Inspector when you need to see what the final endpoint actually returned beyond the status line.
Stack Harbor uses Redirect Tracer as a routine verification step during migrations, vendor changes, and DNS cutovers handled as part of Deployment Management.