GET vs HEAD: what actually crosses the wire
The whole safety argument comes down to one line in the HTTP spec. Both methods send the same request; the server answers with the same status and headers. The difference is the body.
The practical takeaway: a GET pulls the entire destination — potentially a megabyte of HTML, scripts, and third-party trackers — onto whatever machine made the request. A HEAD reads the same headers and stops. For a security analyst triaging a suspicious bit.ly link, that difference is the line between "I found out where it goes" and "I just detonated it on my workstation."
Following the redirect chain, one HEAD at a time
Short links rarely point straight at the destination. They chain: the shortener redirects to a tracking domain, which redirects to a campaign parameter, which finally lands on the real page. An expander walks that chain by issuing a HEAD, reading the Location header, issuing the next HEAD, and repeating.
| Step | Request | Response status | Location header |
|---|---|---|---|
| 1 | HEAD bit.ly/xY7q | 301 Moved Permanently | https://trk.example/c/9f2 |
| 2 | HEAD trk.example/c/9f2 | 302 Found | https://login-secure-verify.example/?u=... |
| 3 | HEAD login-secure-verify.example/?u=... | 200 OK | (final destination) |
| Result | — | chain resolved | flagged: lookalike login domain |
Every 3xx status that carries a Location header — 301, 302, 303, 307, and 308 — is a hop the expander follows. A good expander also caps the chain length (to avoid redirect loops) and shows you every intermediate domain, because the tracking and cloaking domains in the middle are often more telling than the final URL.
Why HEAD is a privacy shield, not a safety guarantee
Here is the part the one-paragraph summary leaves out, and it matters more than the RFC trivia: expanding a URL tells you where it currently points for your request — it does not tell you where it will send the actual victim. Two limitations break the "expanded therefore safe" assumption.
- Cloaking. A malicious server can inspect the request method,
User-Agent, IP range, or geolocation and serve a benign redirect to anything that looks like a scanner while routing real browsers to a phishing kit. Your HEAD request may see a clean destination that a victim never reaches. - HEAD/GET divergence. The spec says HEAD should behave like GET, but nothing forces a hostile server to be honest. It can answer HEAD with a harmless 200 and reserve the redirect for GET requests that carry a full browser fingerprint.
So treat an expanded URL as one signal among several. Cross-reference the final domain against reputation feeds and certificate-transparency logs, watch for lookalike or typosquatting red flags, and when you record the result in a ticket or share it with a colleague, defang it — rewrite https:// as hxxps:// and wrap the dots — so nobody turns your evidence into a live click.
The practical workflow
- Expand server-side. Paste the short link into the tool above so the HEAD requests run on our infrastructure, not your machine. You get the full chain and the final domain without your browser ever touching the destination.
- Read the whole chain, not just the endpoint. Intermediate tracking and redirect domains often reveal the campaign faster than the landing page.
- Verify the destination independently. Check the final domain's registration age, TLS certificate, and reputation before trusting it. HEAD gets you the address; it doesn't vouch for the neighborhood.
- Defang before you share. Any URL going into a report, email, or chat should be defanged so it can't be clicked accidentally.
Used this way, a HEAD-based URL expander is one of the cheapest, highest-leverage tools in phishing triage: near-zero exposure, full redirect visibility, and no chance of your investigation becoming the incident. Just remember what it is — a way to look without visiting — and pair it with the reputation and defanging steps that turn a resolved URL into an actual verdict.