Trace redirects by browser

Enter a URL and choose up to four browsers. We follow each hop and show the status code, the headers and where the link lands for each one.

Results appear here.
Enter a URL above and press Enter or Trace redirects. We run 6 checks and explain each one.

What this checks

Every hop: Status code, Location header, response time and the headers that matter for each redirect.
User agents: iPhone Safari, Android Chrome, desktop Chrome, the in-app browsers of social apps and link preview bots, up to four per trace.
Where each one ends: A web page, an App Store or Google Play listing, or an app link, compared across the user agents you chose.
Loops and long chains: A chain that repeats an address, or runs past the hop limit, is reported with the fix.
HTTPS and final status: A request over plain HTTP is flagged, and so is a last response that is not a success.
Soft redirects and previews: Meta refresh tags and plain location scripts with their delay, noindex directives, and the Open Graph tags that link previews read.

How to trace a link

1
Enter the link
Paste a short link, a campaign link or any URL. We use https when you leave the scheme off, and keep http when you type it.
2
Choose user agents
The defaults are iPhone Safari, Android Chrome, desktop Chrome and Instagram on iPhone. Swap in the app where people tap your link. You can pick up to four.
3
Trace the link
We request the URL as each user agent and follow every redirect, up to ten requests for each chain.
4
Compare where they end
The top rows show each user agent beside the others. A different ending for an in-app browser is the usual cause of a link that opens the browser and not the app.
5
Open a chain
Select a row to read its hops: the status, the Location header, the time and the notable response headers.
6
Apply the fixes
Each finding says what to change. Copy the address bar to share the trace: it holds the link and your choices.

What each redirect status means for links

A server tells a browser, an app or a crawler how to treat a redirect with a status code. The code decides whether the answer is cached and whether the request keeps its method.

301 Moved Permanently: The address moved for good. Browsers and caches may keep the answer, so a later change to the destination can miss people who already followed it. It suits a retired URL and is risky on a link that picks a destination by device.
302 Found: A temporary redirect. Caches do not keep it unless the response says so. It is the usual choice for links that choose a destination by device or campaign.
303 See Other: The client continues with a GET request at the new address. It is common after a form post and rare on links.
307 Temporary Redirect: A temporary redirect where the client repeats the same method and body. For a link it behaves like 302.
308 Permanent Redirect: A permanent redirect like 301, where the client repeats the same method and body.
Meta refresh: A 200 page with a refresh meta tag sends the visitor on, after an optional delay. We read the tag and follow it. A delay shows the page first, and a zero delay still costs a full page load.
Location script: A page whose script assigns the browser location. We follow plain assignments. A script that depends on the page state or on input is not run, and the report marks the page.
4xx and 5xx: A 404 or 410 means the page is missing. A 403 often means the server refuses that user agent, which is common for bots and in-app browsers. A 5xx can be temporary, so run the trace again before you act.

How user agents change where a link goes

A user agent is the name a browser or app sends with each request. Link services and servers read it, so one URL can answer differently for each.

In-app browsers: Instagram, Facebook, TikTok, LinkedIn and X open links in a web view inside the app instead of Safari or Chrome. The user agent carries the app name or a web view marker, and servers can answer it differently.
Universal Links and App Links: iOS and Android decide on the device whether a tapped URL opens an installed app. A tap inside an in-app browser often stays on the page because the web view does not hand the URL to the system. A chain shows what the server does, not what the device does.
Custom schemes: An address such as myapp://open can open an app, and many in-app browsers block it. The checker warns when an in-app chain ends on one.
Link preview bots: Facebook and Slack fetch a link with their own user agent to build a preview card. They need a web page with Open Graph tags, not a redirect to a store listing.

How to read a result

The report goes from the answer to the detail: where each user agent ends, then each hop, then what to fix.

Comparison rows: One row per user agent with its redirect count, where it ended and how long it took. Select a row to open its hops.
Letters A, B and C: When the user agents end in different places, rows with the same letter ended at the same address.
Status chips: Green for 2xx, teal for 3xx redirects, red for 4xx and 5xx. The number is always shown, so colour is never the only cue.
Soft redirect markers: Meta refresh and Script redirect mark a hop that comes from the page body. Waits shows the delay before it fires.
noindex: The page or its headers ask search engines not to index it. This matters when the page is a landing page you want to rank.
Findings: Each finding names what we saw, passes or flags it, and gives the change to make. Use Needs attention to hide the passes.

Why the same link lands in different places

A link service reads the user agent and the headers of each request, then chooses where to send the visitor. A phone, a desktop browser and the in-app browser of a social app can each receive a different chain from the same URL.

This checker sends the user agent you pick and reports what the server answers. We follow HTTP redirects, simple meta refresh tags and plain location scripts. We do not run full JavaScript or open apps, and Universal Links and App Links are decided on the device.

Frequently asked questions

Does this run a real browser?

No. It sends an HTTP request with the user agent you pick and follows the redirects the server returns, plus simple meta refresh tags and plain location scripts. It does not run full JavaScript, so a redirect that needs page code to decide is flagged and not followed.

Why does the same link end in different places?

Link services read the user agent, so a phone, a desktop browser and an in-app browser can each get a different chain. A smart link sends iPhones to the App Store and Android to Google Play on purpose. A plain link that does this by accident is the one to fix.

Which user agents can I choose?

Browsers (iPhone Safari, Android Chrome, desktop Chrome), in-app browsers (Instagram, Facebook, TikTok, LinkedIn, X, the Google app and Android web views) and link preview bots (Facebook and Slack). Choose one to four for each trace.

Can a redirect break Universal Links or App Links?

Yes. A redirect in front of the apple-app-site-association file hides it from iOS, and a link that redirects before it reaches your associated domain opens in the browser, because the device matches the URL the person tapped. Check the domain with the deep link checker.

Why does a social app open a web page and not my app?

Many in-app browsers do not hand links to installed apps. The chain can be correct while the in-app browser keeps the visitor on the web page. Our guide to in-app browsers covers the fixes.

Which addresses and limits apply?

We request public web addresses on the standard ports. A redirect to a private or internal address is reported and not requested. One trace makes up to 24 requests across all user agents, and counts as three checks against the per-minute limit shared by our free tools.

Related tools

We handle the routing for you

WarpLink serves your short links with the right destination for each device and browser, and records the click. You skip hand-written redirect rules.

Start buildingFree to start. No sales call.