URL Expander

URL expansion (also called unshortening) resolves shortened links such as t.cn, bit.ly or TinyURL back to the real destination. A short-link service works by storing a mapping from a short code to the original long URL: when someone visits the short link, it answers with an HTTP 3xx redirect that sends the browser to the real page. This tool requests the short link hop by hop on the server side, follows the Location header of every redirect, and reports the final URL together with the complete redirect chain, the number of hops, each hop's status code and the total time. It is handy for checking where an unfamiliar link actually leads before clicking it, verifying that a promotional link you configured resolves correctly, and debugging redirect setups. Two boundaries are worth knowing: only redirects carried by HTTP work — in-page Meta Refresh or JavaScript redirects are invisible to it; and the expanded URL is not a safety verdict — phishing links redirect perfectly normally, so the destination domain still deserves your own scrutiny.

A short link is nothing more than a web service that answers with a redirect. The HTTP specification (RFC 9110, formerly RFC 7231) defines the 3xx family: 301 and 308 mean the resource moved permanently, 302, 303 and 307 are temporary. In every case the actual destination travels in the Location response header — the status code itself carries no address. A short-link service stores the short-code-to-long-URL mapping in a database, looks it up once per request, and its job is done the moment it returns a 3xx plus a Location header. That is why short links can be so short, and why expanding one is simply a matter of following the Location headers.

The expansion itself runs on the server side. The HTTP client is configured to never follow redirects automatically: for each request it inspects the status code — if it is a 3xx, the Location value (which may be a relative path, resolved against the current URL as RFC 7231 allows) is requested next; anything else means the final page has been reached. Every hop re-validates that the target is a public address, so a malicious short link cannot steer the expansion probe at an internal network (SSRF), and the chain is capped at 10 hops, beyond which it is declared a redirect loop and stopped. Each hop reads only the response headers and closes the connection without downloading the page body, so the total time is essentially the sum of the per-hop network round trips — typically a few hundred milliseconds.

The detection boundary matters just as much: Meta Refresh (<meta http-equiv="refresh">) and JavaScript redirects live inside the page content and generate no HTTP status at all, so a server that only reads headers cannot see them — these "invisible" redirects happen only once a browser actually renders the page. Finally, some short-link services vary their response by User-Agent or visitor region; this service probes with a generic browser UA so the chain you see approximates what a real visitor would experience.

• A 3xx status code (301/302/303/307/308) plus the Location response header is the entire redirect mechanism; the destination travels only in that header.
• 301/308 permanent redirects are cached by browsers and search engines; 302/307 temporary redirects re-query the short-link service on every visit.
• Hop-by-hop following: on every 3xx the address in Location is requested next, until a non-3xx arrives; a 10-hop cap guards against redirect loops.
• Location may be a relative path (permitted by RFC 7231) and is resolved against the current hop's URL into an absolute address.
• Each hop reads only response headers and closes the connection immediately, without downloading the page body — a typical expansion takes a few hundred milliseconds.
• SSRF protection: every hop re-validates the target address and rejects private/loopback ranges, so a hostile short link cannot probe an internal network through the tool.
• The same-origin policy stops a browser from reading arbitrary sites' response headers, which is why cross-site expansion must be proxied through a server.