Free Tool

Free Redirect Chain Checker

Trace the complete redirect chain of any URL. See every hop, status code, response time, and the final destination. Free SEO tool for marketers, developers, and security researchers. No signup, instant results.

Enter URL to check

No signup required

Free forever

GDPR compliant

Quick Answer

A redirect checker traces all HTTP redirects (301, 302, 303, 307, 308) from a starting URL to its final destination. The U2L tool shows each hop with its status code, response time, HTTPS status, and domain so you can debug broken short links, audit SEO redirects, and verify safe destinations before clicking shortened URLs.

Quick Facts

HTTP redirects come in five flavors: 301 (permanent), 302 (temporary, default), 303 (see other), 307 (temporary preserving method), 308 (permanent preserving method).
Search engines treat 301 and 308 as 'follow + transfer ranking signals'; 302 and 307 as 'follow but keep ranking on the original URL'. Confusing the two costs SEO equity.
Excessive redirect chains (4+ hops) hurt page-load time and SEO. Google warns about chains of 5+ redirects in Search Console.
HTTPS-to-HTTP downgrades inside a redirect chain are a security flag. Always verify the final URL is HTTPS before submitting credentials.
Major shorteners (Bitly, TinyURL, t.co) typically use 302 redirects so they can change destinations later without losing SEO equity from the short URL.
Some destinations strip query parameters or referer headers during redirect; UTMs and tracking IDs may not survive the full chain.
Redirect loops (A redirects to B redirects to A) are detected by browsers after ~20 hops and shown as ERR_TOO_MANY_REDIRECTS.

How to check a URL's redirect chain

Three steps. Paste, check, inspect.

1
Paste the URL
Any URL: shortened (bit.ly, tinyurl.com), branded short (yourbrand.link), or long (the full destination). The tool follows whatever's in the URL field, including HTTP-to-HTTPS upgrades and trailing-slash redirects.
2
Click Check
U2L's server-side checker fetches the URL and follows redirects up to 20 hops. Each request is made from a Cloudflare edge node, so the timing reflects real-world performance from a major datacenter.
3
Read the chain
Each hop shows the URL, HTTP status code (301/302/etc), response time in milliseconds, and HTTPS status. Final destination is highlighted. Look for unexpected hops, HTTPS downgrades, or excessive total time.

What is a Redirect Checker?

Redirect Checker is a tool that fetches a URL, follows every HTTP redirect, and shows you the complete chain of hops from the input URL to the final destination. The U2L Redirect Checker handles up to 20 hops, distinguishes redirect types (301 permanent vs 302 temporary), times each hop, and flags HTTPS-to-HTTP downgrades. Free, server-side, no signup, no rate limits for normal use.

Redirect chains hide complexity. A short URL like bit.ly/abc may redirect to a tracking subdomain, then to an HTTPS variant, then to the final destination - three hops the user never sees because the browser handles them transparently. Each hop adds latency, breaks UTM attribution if mishandled, and creates a potential point of failure. A redirect checker exposes the chain so you can debug, audit, or verify safety.

Marketers use redirect checkers to debug broken campaigns: a Bitly link that suddenly stops working might have a redirect to a deleted destination, an SEO checker can confirm permanent (301) redirects are configured correctly during a site migration, and a developer can verify load balancer redirect rules don't strip query parameters in production.

Security-aware users use redirect checkers as a safety check before clicking shortened URLs from unknown sources. If bit.ly/x9k2m redirects through a sketchy domain before reaching the real destination, you see it before tapping the link. This is especially valuable for short links shared in emails, SMS, or social media where the destination is hidden.

How does a Redirect Checker work?

When you submit a URL, U2L's server-side checker runs at the Cloudflare edge. It sends an HTTP HEAD request (or GET if HEAD isn't supported) with a normal Chrome User-Agent so the destination behaves identically to a real browser. The server captures the HTTP status code, the Location header (which contains the next URL to follow), the response time, and the HTTPS status. It then repeats the process for the next URL in the chain, up to 20 hops total.

The 20-hop limit prevents redirect loops from running indefinitely and matches the limit major browsers enforce (Chrome, Firefox, Safari all bail at 20-30 hops). If the URL still hasn't reached a final destination by hop 20, the checker stops and flags the chain as suspicious. Real-world chains rarely exceed 5 hops; anything longer is usually a misconfiguration or a tracking pixel chain that's escaped its intended depth.

Each redirect type has different semantics. 301 (Moved Permanently) tells search engines and browsers to update their cache: the new URL is canonical. 302 (Found, formerly Moved Temporarily) means 'follow this redirect for now, but keep using the original URL as canonical.' 303 (See Other) is used after POST requests to redirect to a GET. 307 and 308 are the strict-method versions of 302 and 301 respectively (don't change POST to GET during the redirect). For SEO, 301 and 308 transfer ranking signals; 302 and 307 don't.

HTTPS-to-HTTP downgrades happen when a chain starts on HTTPS and at some hop drops to HTTP. The browser's omnibox no longer shows the lock icon, and any data the user submits on the final page is unencrypted. Modern browsers warn about this; the redirect checker flags it visually with an HTTP badge so you can decide whether to trust the chain.

Use Cases

How marketers, businesses, and developers use redirect checker.

SEO audits during site migrations

When migrating a site to a new domain or restructuring URLs, every old URL needs a 301 redirect to its new counterpart. A checker confirms each old URL resolves to the right new page with the right status code. Catching a 302 where you wanted a 301 prevents weeks of lost ranking equity.

Debugging broken short links

A campaign link that 'used to work' often broke because an intermediate hop changed: the destination URL moved, the tracking subdomain was deprecated, or a load balancer rule changed. The checker shows exactly which hop is failing, isolating the fix.

Verifying safe destinations

Before clicking a suspicious shortened URL (in email, SMS, or social media), paste it into the checker. You see the full chain, including any sketchy intermediate domains. If the destination is malicious, you avoid the click; if it's safe, you proceed with confidence.

Confirming UTM survival through redirects

Some redirect chains strip query parameters mid-chain, breaking UTM attribution. The checker shows the URL at each hop, so you can verify your utm_source and utm_medium params arrive at the final destination.

Tracking redirect performance

Slow redirects compound page-load time. A 4-hop chain with each hop taking 200ms adds 800ms before the user sees the destination. The checker shows per-hop timing so you can identify and fix the slow hop.

HTTPS upgrade verification

After enabling HTTPS, every old HTTP URL should redirect to its HTTPS counterpart. The checker confirms the redirect fires correctly and that the redirect type is 301 (so search engines update their index).

Affiliate link audit

Affiliate networks insert tracking subdomains between the affiliate URL and the merchant. The checker reveals these intermediate hops, which sometimes break or degrade if the affiliate network has issues. Compliance teams use this to verify disclosed affiliate paths.

Localization redirect testing

Multi-language sites redirect users to /en, /es, /fr, etc. based on Accept-Language. The checker hits the URL with a specific User-Agent so you can verify the redirect chain matches the expected locale-routing logic.

Verifying canonical URL configuration

Pages should have one canonical URL; HTTP, HTTPS, www, and trailing-slash variants should all 301 to the canonical version. The checker confirms each variant lands on the right canonical destination.

Pre-launch QA for marketing campaigns

Before a major campaign goes live, run every campaign URL through the checker. You catch broken links, wrong redirects, and stale destinations before they hit ad spend. Standard pre-launch checklist for performance marketing teams.

Redirect Checker vs Alternatives

Side-by-side feature and pricing comparison with the top alternatives.

Feature	U2L	RedirectDetective	WhereGoes	WheretoGo	httpstatus.io
Free tier with no rate limit		Limited			Limited
Per-hop response time
HTTPS / HTTP flag per hop
Status code labels (301/302/etc)
Up to 20 hops		10 hops		5 hops
Custom User-Agent	Chrome	Generic	Chrome	Generic	Generic
SSRF protection		Unclear	Unclear	Unclear	Unclear
No signup

Redirect Checker vs WhereGoes

WhereGoes is a popular free redirect checker focused on simplicity. It shows the chain, status codes, and timing - the basics covered. The interface is plain HTML; the experience hasn't changed much in years.

U2L's redirect checker offers identical core functionality with a cleaner UI, sub-50ms edge response from Cloudflare, and SSRF-protected server-side checking that prevents the tool from being used to scan internal networks. For one-off checks, either works; for daily use, U2L's UI is easier on the eyes.

Redirect Checker vs httpstatus.io

httpstatus.io is the developer-focused checker, popular in SEO and dev circles. It exposes raw HTTP headers per hop, which is great for advanced debugging but overkill for typical use cases.

U2L's redirect checker focuses on the SEO/marketing/security use case: clean output showing status, time, HTTPS, and domain per hop. For raw header inspection, httpstatus.io is better; for marketing-focused redirect debugging, U2L's UI converts faster.

Best Practices

Use 301 for permanent redirects, 302 for temporary

Search engines transfer ranking signals through 301 (and 308) but not through 302 (or 307). For permanent URL changes (site migration, URL restructure), always use 301. For A/B testing or temporary maintenance redirects, use 302.

Keep redirect chains under 3 hops

Each hop adds latency. A 5-hop chain at 100ms each is half a second of redirect overhead before the page even starts loading. Aim for direct redirects (1 hop) for production traffic; up to 3 is acceptable for legacy paths.

Always end on HTTPS

HTTP-to-HTTPS upgrades should happen at the first hop, not the last. If the chain ends on HTTP, the user submits any form data over an unencrypted connection. Browser warnings will erode user trust.

Test all variants of canonical URLs

Run http://example.com, http://www.example.com, https://www.example.com, and https://example.com through the checker. They should all 301 to the same canonical URL. Inconsistent canonicalization splits ranking signals across variants.

Don't strip query parameters during redirects

Some web servers strip query strings during redirects (e.g. /old?id=123 -> /new without the ?id=123). This breaks UTMs, session IDs, and any URL-passed parameters. Configure the redirect to preserve query strings explicitly.

Use HSTS to skip the HTTP-to-HTTPS hop

Strict-Transport-Security headers tell browsers to upgrade HTTP requests to HTTPS automatically without a server round-trip. Combined with HSTS preload, you save a hop on every first visit. Configure once in your server / CDN.

Audit redirects after every site change

URL restructures, CMS migrations, and load balancer rule changes can quietly break redirects. Make redirect-checker scans part of your release checklist; running 50 critical URLs through the checker takes 5 minutes and catches surprises before users do.

Don't redirect from a 200 page

JavaScript or meta-refresh redirects from a 200-OK page have weaker SEO signal than HTTP redirects. Always use HTTP-level redirects (server-side or CDN) for canonical URL changes; reserve client-side redirects for special cases like A/B testing.

Common Mistakes to Avoid

Using 302 when you mean 301

Many web servers default to 302 (which doesn't transfer ranking equity). For permanent URL changes, you must explicitly configure 301. The checker reveals which type is being sent so you can fix the config.

Chaining redirects (A -> B -> C -> D)

Each intermediate redirect adds latency and dilutes ranking signal. Always redirect directly to the final destination from the source URL. Chains usually creep in over time as redirects are stacked rather than consolidated.

Stripping query parameters during redirect

Server configurations can drop the query string on redirect. The checker shows the URL at each hop so you can verify ?utm_source survives. If it doesn't, fix the redirect rule (most servers have an option to preserve query string).

HTTPS-to-HTTP downgrade in chain

Starting on HTTPS and dropping to HTTP mid-chain breaks security indicators. The checker flags HTTPS/HTTP per hop. Always end on HTTPS; if the destination only supports HTTP, fix that destination.

Allowing redirect loops

A -> B -> A causes ERR_TOO_MANY_REDIRECTS in browsers. The checker bails at 20 hops and flags the loop. Loops typically result from misconfigured load balancers, conflicting CDN rules, or overlapping redirect tables.

Ignoring slow hops

A 600ms response on a single hop in an otherwise fast chain points to a slow upstream service or DNS misconfiguration. The checker's per-hop timing makes the slow hop visible. Address it before users complain about page-load times.

Not testing internationally

Redirects can behave differently from different geographic regions due to CDN routing, GeoIP rules, or locale-specific redirect tables. The U2L checker hits from Cloudflare edge; for region-specific testing, use a VPN or a multi-region checker.

Technical Specifications

Maximum hops followed	20 (matches major browsers; bails on loops)
Redirect types tracked	301, 302, 303, 307, 308 (and any other 3xx)
Request method	HEAD with GET fallback (matches browser behavior)
User-Agent	Recent Chrome desktop UA so destinations behave normally
Timing	Per-hop response time in milliseconds
HTTPS detection	Per-hop, flags downgrades visually
SSRF protection	Yes; loopback, private IPv4, private IPv6, link-local, cloud metadata blocked
Redirect URL extraction	Location header + HTML body fallback for stripped headers
Server location	Cloudflare edge (closest to user)

Industry-Specific Use Cases

SEO and digital marketing agencies

Daily checks of client redirects during migrations, ranking audits, and campaign launches. The checker is part of every standard pre/post-launch checklist; broken redirects cost ranking and ad spend.

Web development and DevOps teams

Redirect rules in load balancers, CDNs, and reverse proxies are a frequent source of subtle bugs. Engineers run the checker against staging and production after every deploy that touches redirect config.

Security and incident response teams

When investigating phishing campaigns and suspicious URLs, the checker exposes the full chain including any cloaking domains. Standard tool in the IR analyst toolkit alongside VirusTotal and URLScan.

Affiliate marketing operators

Affiliate networks insert tracking subdomains between the affiliate URL and the merchant. Operators verify their affiliate paths haven't broken; compliance teams audit disclosed affiliate chains.

E-commerce engineering

Product page restructures, category renames, and seasonal redirects all need 301 audits. Running the checker against a list of top 100 product URLs catches issues before they hit search-rank reports.

Email marketing teams

Email links go through email service provider tracking redirects, then sender domain redirects, then the final destination. A 4-hop chain in an email is normal; checking it ensures nothing breaks during send-day load.

Frequently Asked Questions

What does a redirect checker do?

It traces the full chain of HTTP redirects from a starting URL to its final destination. For each hop, it shows the URL, status code (301/302/etc), response time, and whether the connection is HTTPS. Useful for SEO audits, debugging broken short links, and verifying the safety of shortened URLs before clicking.

What's the difference between 301 and 302 redirects?

301 (Moved Permanently) tells search engines and browsers the URL has permanently moved; ranking signals transfer to the new URL. 302 (Found) says the move is temporary; ranking stays with the original URL. For permanent site migrations always use 301; for A/B testing or maintenance use 302.

How many redirects can it follow?

Up to 20 hops. Beyond that, the checker stops and flags the chain as suspicious or looping. Major browsers (Chrome, Firefox, Safari) also bail at 20-30 hops, so the limit matches real-world browser behavior.

Does it follow JavaScript or meta-refresh redirects?

No. The checker follows HTTP-level redirects (3xx responses with Location headers) only. JavaScript redirects (window.location.href) and meta-refresh redirects happen client-side and aren't part of the HTTP chain. For JS redirect testing, use a headless browser tool.

Is the checker free?

Yes, free with no rate limits for normal use. Heavy scraping (1000+ checks per minute) may be throttled to keep the service stable for everyone, but typical SEO and developer use never hits the limit.

Will the checker work for password-protected URLs?

Partially. The redirect chain shows up correctly, but if a hop returns a 401 or 403 (authentication required), the checker stops there. The URL up to that point is visible; behind the auth wall is not.

Can it scan internal/private URLs?

No. The checker has SSRF protection: requests to loopback (127.0.0.1), private IPv4 ranges (10.x, 192.168.x), private IPv6, link-local, and cloud metadata endpoints are blocked. This prevents the tool from being used to scan internal corporate networks via the public service.

What if the destination is down?

The checker shows the chain up to the failure point and flags the broken hop with the actual status code (404, 500, etc.) or a network error. You can see exactly where in the chain the failure occurs.

Does it preserve UTM parameters?

The checker doesn't modify the URL it sends; UTMs and other query parameters in your input URL are passed through as-is on the first request. Whether they survive each subsequent redirect depends on the destination's redirect configuration. The checker reveals where they're stripped if anywhere.

How accurate are the timing measurements?

Each hop's response time is measured from the request being sent to the response headers being received. The total time is the sum of all hops. The checker runs from Cloudflare edge nodes, so timing reflects real-world performance from a major datacenter (typically faster than residential broadband).

Does it handle URL fragments (#anchor)?

Fragments are client-side only - they don't appear in HTTP requests. The checker ignores them in the input URL and the output. For verifying anchor-based redirects (e.g. SPA route changes), use a headless browser tool instead.

Why does my browser show a different chain than the checker?

Browsers cache redirects (especially 301s) so subsequent visits skip cached hops. The checker always fetches fresh, so you see the canonical chain. Browser dev tools' Network tab with 'Disable cache' enabled shows the same chain as the checker.

Can it detect redirect loops?

Yes. The checker stops at 20 hops and flags the chain as a loop or excessive. If you see hop counts climb past 5-6, that's a configuration problem in the destination's redirect rules.

What's the difference between this and the URL Expander?

Both follow redirects, but the URL Expander focuses on revealing the final destination (e.g. 'this bit.ly link goes to youtube.com/watch'). The Redirect Checker focuses on the full chain with per-hop detail (status codes, timing, HTTPS) for debugging and auditing.

Does it work for shortened URLs from any service?

Yes. Bitly, TinyURL, t.co, dub.sh, lnkd.in, ow.ly, buff.ly, j.mp, and any other URL shortener that uses standard HTTP redirects all work. The checker doesn't care which shortener; it just follows whatever redirects are returned.

Will redirect checking cost the destination money?

Each check makes one HTTP request per hop, similar to a single page load. For most destinations the cost is negligible (sub-cent for a typical CDN-backed page). Don't run thousands of checks in a tight loop; that crosses into abuse territory.

Can I share the result?

Currently the result is per-session only. To share, take a screenshot or copy the URL chain manually. We may add shareable result URLs in a future update if there's demand.

Does the checker bypass paywalls or login walls?

No. The checker uses a normal Chrome User-Agent without any authentication. If the destination requires login (e.g. paywalled news, subscription portal), the checker hits the login redirect like any other anonymous user would.

Is the data shown in real-time?

Yes. Each check fetches live data from each URL in the chain. There's no caching of redirect chains; the result reflects exactly what the chain looks like at the moment you click Check.

What if a redirect uses HTML body instead of Location header?

Some servers return a 200-OK page with an HTML refresh tag instead of a proper 301/302 response. The checker tries to extract the redirect URL from the HTML body in this fallback case, but JavaScript-only redirects are out of scope (use a headless browser).

Related Free Tools

WhatsApp Link Generator

Create wa.me click-to-chat links with prefilled messages. Add to your bio, ads, or QR codes for instant WhatsApp customer chats.

OG / Metatag Checker

Inspect Open Graph and Twitter Card tags for any URL. Preview link cards on Facebook, X, LinkedIn, and Slack before publishing.

URL Encoder / Decoder

Encode or decode any URL. Handle special characters, query strings, and percent-encoding. Pure browser, instant.

Schema Markup Generator

Generate valid JSON-LD schema for FAQ, HowTo, Article, Product, and Organization. Boost rich results and AI Overview citations.

URL Expander

Reveal the full destination behind any shortened URL. Check where a short link leads before clicking it.

Bulk URL Status Checker

Check status codes for hundreds of URLs at once. Find broken links, redirects, and slow pages. CSV export.

See all 50 free tools

Key Terms

HTTP redirect: A 3xx HTTP response code that tells the client to fetch a different URL. Common types: 301 (permanent), 302 (temporary, default), 307 (preserves request method), 308 (permanent + preserves method).
Location header: The HTTP header in a redirect response that specifies the next URL to fetch. The browser follows it transparently. The redirect checker reads this header on each hop to discover the next URL.
Hop: A single redirect step in the chain. The starting URL is hop 1; each redirect adds another hop. Final destination is the last hop with a 200 (or non-3xx) status code.
Redirect chain: The sequence of URLs traversed from the starting URL to the final destination. A chain of length 1 means no redirects; length 5 means 4 redirects between start and final.
SSRF (Server-Side Request Forgery): A class of vulnerability where an attacker tricks a server into making requests to internal addresses. The checker has SSRF protection: loopback, private IP ranges, link-local, and cloud metadata endpoints are blocked.
HSTS (Strict-Transport-Security): An HTTP header that tells browsers to always upgrade HTTP requests to HTTPS for the domain, without a server round-trip. Eliminates one hop in HTTP-to-HTTPS chains and improves first-visit performance.

Need full analytics on every redirect, not just a one-time check?

U2L short links record every click with destination, country, device, and time-of-day. Free for the first 30 days; upgrade for unlimited tracking and custom domains.

Get a tracked short link free