Decode Outlook SafeLinks, Proofpoint URLDefense, Google redirect links and other wrapped URLs back to the original destination so you can inspect where a link really goes.
Unwrap Outlook SafeLinks, Proofpoint URLDefense and other rewritten URLs. Corporate mail gateways rewrite every link in an email so clicks pass through their scanner first. Paste the rewritten link here to recover the real destination before you open it.
Paste the full link, including the query string. Nothing leaves your browser.
Why your links get rewritten, and how to read them
What a link wrapper does
When an organisation runs Microsoft Defender for Office 365, Proofpoint, Mimecast or a similar gateway, every URL inside an inbound email is rewritten before it reaches the mailbox. example.com/report becomes something like eur01.safelinks.protection.outlook.com/?url=htt....
The point is time-of-click protection. A link can be harmless when the message is scanned and weaponised an hour later, so the gateway forces every click back through its own scanner and re-checks the reputation of the destination at that moment.
The cost of wrapping
Wrapping breaks the oldest security advice in the book: hover over a link and read where it goes. The status bar now shows the gateway's domain, not the real one. It also breaks link previews, makes URLs unusable in documentation, defeats copy-paste into a terminal, and leaks click telemetry to the gateway operator.
Decoding restores the original URL so you can judge it yourself.
The formats
Outlook SafeLinks puts the destination in a url query parameter, percent-encoded once. Everything after it (data, sdata, reserved) is tracking metadata that can be discarded.
Proofpoint URLDefense has three generations. v1 and v2 use a u parameter with a custom substitution: - stands for % and _ stands for /. v3 uses a path-based __example.com__;!!... form. This tool reverses the substitution before percent-decoding.
Google uses /url?q= (search results) or /url?url= (other products), and Facebook, LinkedIn and Twitter each have their own equivalent.
Generic wrappers put the destination in a parameter named url, u, target, redirect, dest or link. The decoder scans for any of these when it cannot identify a known vendor.
Reading a decoded link safely
Getting the URL back is only half of the job. Check the registrable domain, not the whole string — paypal.com.secure-login.ru belongs to secure-login.ru. Watch for lookalike characters, an unexpected top-level domain, or a legitimate host with a strange path such as /wp-content/uploads/. And remember: a decoded link that looks fine is not proof the file behind it is safe.
Frequently asked questions
Is it safe to decode a suspicious link here?
Yes. The decoding is pure string manipulation inside your browser — no request is made to the link and nothing is sent to a server. You are reading the URL, not visiting it.
Why does the decoded link still contain strange parameters?
Marketing parameters such as utm_source, gclid or fbclid belong to the original URL and survive unwrapping. They are safe to strip manually if you want a clean link.
It says 'not wrapped' but the link came from an email.
Not every gateway wraps every link. Internal senders, allow-listed domains and plain-text messages are often left untouched, so there is simply nothing to unwrap.
Can I turn SafeLinks off?
Only a tenant administrator can, through Defender for Office 365 policies, and disabling it removes time-of-click protection for everyone. Decoding individual links is the safer habit.
What about nested wrappers?
Links forwarded between organisations can be wrapped twice. Decode the result again and the second layer comes off too.