[ E.12 — LINK UNWRAPPER ]

Email Link
Unwrapper.

Email security products rewrite every link in a message so clicks route through their scanner. The result hides where the link actually goes — exactly when you are trying to decide whether to trust it. Paste the rewritten URL and this shows the real destination.

Corrections welcome — see our editorial policy.

Try a sample link

Decoded in this browser tab. The link is never sent to us — which matters, because a wrapped URL carries your organisation's identifiers and a token tied to the message it came from.

Read the headers behind the message.

Analyze a message header →

Why the link in your inbox is not the link

Most managed mail now passes through a security product that rewrites URLs before delivery. Microsoft calls it Safe Links, Proofpoint calls it URL Defense, and Mimecast, Cisco and others each have their own. The mechanism is the same: every link in the message body is replaced with one pointing at the vendor, carrying the original address inside it. When you click, the vendor checks the destination first and only then sends you on.

The reason is sound. A link that was harmless when the message was scanned can be weaponised an hour later, and rewriting is the only way to get a check at the moment of the click rather than at the moment of delivery. What it costs is legibility. A rewritten link is often several hundred characters of vendor hostname, encoded payload and tracking identifiers, and the destination is buried somewhere in the middle. Hovering tells you nothing useful.

That trade lands hardest in the one situation it should help with most. Someone forwards a message and asks whether it is a phish. The ordinary first move — look at where the link goes — is unavailable, because the link goes to the security vendor. This tool restores that first move.

What actually gets encoded

The wrappers split into two groups, and the difference decides whether anything can be recovered at all.

Some carry the original URL inside the link. Microsoft Safe Links puts it in a url= parameter. Proofpoint's v1 and v2 formats use u=, with v2 additionally swapping - for % and _ for / before the usual percent-encoding. LinkProtect (linkprotect.cudasvc.com) uses a=. Google's redirect uses q=. In every one of these the original is genuinely present, and decoding is reversible string work with no lookup required.

Others carry only a token. Mimecast's protect-…/s/ links and Cisco Secure Email's secure-web.cisco.com links identify a record on the vendor's own service. The original address is not in the link in any form. No tool can decode one, because there is nothing to decode — only the vendor holds the mapping. When you paste one here, this page says so rather than producing something that looks like an answer.

That distinction is worth internalising beyond this tool. If a site claims to unwrap a Mimecast link without contacting Mimecast, it is either following the redirect on your behalf, which tells the sender someone opened the link, or it is guessing.

The Proofpoint v3 format, and why we sometimes hedge

Proofpoint's current format is the most involved. It looks like urldefense.com/v3/__<address>__;<data>!!<identifiers>$. The address sits between double underscores, but certain characters have been lifted out and replaced with asterisks; the characters themselves travel base64-encoded in the section after the semicolon. Reconstructing the URL means walking the address, and each time an asterisk appears, putting back the next character from the decoded set.

Most of the time this resolves cleanly and you get an exact original. Occasionally it does not — a truncated paste, a link mangled by the mail client, or a placeholder form we do not fully account for. When that happens this page tells you the reconstruction is partial instead of showing a confident answer.

That is a deliberate choice and the most important one here. The moment you use a tool like this is the moment you are deciding whether to trust something. A wrong hostname delivered confidently is worse than no answer at all, because no answer sends you to check another way, whereas a wrong answer ends the investigation with the wrong conclusion. Every result is validated before it is shown: it has to parse as a real web address with a plausible hostname. Anything that fails that check is labelled rather than presented as fact.

Wrappers stack

A message can pass through more than one product — a mail gateway at the edge and a mailbox-level scanner behind it — and each rewrites what the previous one produced. It is common to find a Proofpoint link inside a Safe Links wrapper. This unwraps repeatedly and shows each layer, so you can see the route as well as the endpoint. That chain is occasionally the interesting part: it tells you which products touched the message, which is a detail that can be worth knowing when the message is suspicious.

Reading the result

What comes back is the destination the wrapper was hiding, and nothing more. It is not a verdict. A link can decode to a perfectly ordinary-looking address and still be hostile — a compromised legitimate site is the standard shape of a modern phish, and it will decode to exactly the domain you expect to see.

What the destination does tell you is whether it matches the story the message is telling. An invoice from a supplier that resolves to a file-sharing subdomain nobody at that supplier uses, a password reset that points somewhere other than the service it claims to be from, a bank notice that lands on a lookalike domain — those are answerable from the destination alone, and that is what the wrapper was preventing you from seeing.

Why the result is not a clickable link

It would be easy to render the destination as something you could click, and this page deliberately does not. If you are unwrapping a link, you do not yet trust it. Making the risky action the easiest thing on the screen would undo the protection the wrapper was providing, and a single mis-aimed tap on a phone would land you exactly where you were trying to avoid.

So the address is shown as selectable text with a copy button. If you decide it is safe, copying it takes a moment. If you decide it is not, you have not been one careless tap away from the site the whole time you were reading.

What this tool does not do

It does not visit the link. Nothing is fetched, followed, or previewed. Requesting the destination would tell whoever controls it that the address is live and being examined, and on a tracking link it would register as engagement from whoever sent it.

It does not send the link anywhere. All decoding happens in this browser tab. A wrapped URL carries your organisation's tenant identifiers and a token tied to a specific message, so uploading one would leak who received what — from a message you already suspect.

It does not judge the destination. There is no reputation check, no blocklist lookup, no verdict. Decoding and judging are different jobs and mixing them would imply a level of assurance this cannot give.

It cannot resolve token-based wrappers. Mimecast and Cisco Secure links are named and explained, not decoded, for the reason given above.

Common questions

Is it safe to paste a link from a suspicious email here? Pasting is safe in the sense that nothing is fetched and nothing is transmitted; the text stays in your browser. Treat the wrapped URL itself as sensitive though, because it identifies your organisation and the message.

The destination looks fine. Does that mean the message is legitimate? No. It means the destination is not obviously wrong. Compromised legitimate sites are common, and the domain alone cannot tell you the difference. Use it to rule things out, not to rule them in.

Why does my Mimecast link not decode? Because the original address is not inside it — the link is a reference to a record only Mimecast holds. Any tool that appears to decode one is following the redirect, which is a different and noisier action than it sounds.

Can I get the original link another way? The raw message source usually still contains it. Most mail clients can show the original message, and the pre-rewrite URL is often present in the headers or an alternative body part. Our email header analyzer is built for reading that source.

Why does the tool say the reconstruction is partial? Because part of the encoded address could not be resolved with certainty, usually from a truncated or reflowed paste. Try copying the link again directly from the message rather than from a forward.

If the message itself is what you are assessing rather than one link in it, the header analyzer shows the delivery path and authentication results, and the DMARC checker shows whether the sending domain publishes a policy that would stop a forgery.