Safe Link Decoder

about this tool

Seeing past a rewritten link

Email security services rewrite every link in a message so that a click goes through their servers first, to be checked at the moment it is made. The rewritten link is long, starts with someone else's domain, and hides the one thing you want to know before clicking: where it goes.

The real address is still in there. Paste one link, a list, or a whole email, and each link is unwrapped in the page, with nothing opened: no request reaches the security service or the site it leads to, which for a suspicious message also means no signal to the sender that it was read.

What it understands

• Microsoft 365 link protection (…safelinks.protection.outlook.com, and the Teams equivalent) keeps the address in its url parameter.
• Proofpoint (urldefense.com, urldefense.proofpoint.com) has three formats: v1 percent-encodes the address into a parameter, v2 writes - for % and _ for /, and v3 replaces the characters it cannot leave in place with * and keeps them, base64-encoded, at the end. All three are decoded as Proofpoint's own decoder does; a link it might read differently is reported as unreadable rather than guessed.
• Barracuda, Symantec and Trend Micro click-time protection.
• The Google, Facebook, Instagram, YouTube and Slack redirects, recognised by their own domains only, so a look-alike such as google.evil.com is not taken for Google.

Any other site with a parameter such as url= or redirect= is not unwrapped: it decides for itself where to send a visitor, so the address in the parameter is shown as what that site says, not as where the link goes. That is how phishing pages pass themselves off as the sites they name.

A link wrapped twice, as when one service forwards to another, is unwrapped layer by layer, and each layer is listed. Mimecast links and link shorteners such as bit.ly keep the target on their own servers; only opening them would reveal it, and the tool says so rather than guessing.

What it checks

The decoded address is shown as a browser would read it, with the site it goes to set apart, and with warnings for the tricks phishing relies on: invisible or text-reversing characters that disguise an address, a target that is a javascript: or data: link rather than a page, a user name before an @ that looks like a site (https://bank.com@evil.example), an internationalised name whose letters only look familiar, shown in its own letters too, a bare IP address, an unencrypted http link, an unusual port, and a link straight to a file to download. Tracking parameters such as utm_source, fbclid and gclid are listed, with a clean copy of the address without them.

Links pasted from a message's HTML source are read as a browser reads them, with character references such as . decoded; a site name that would still hold encoded characters is refused rather than guessed. A decoded link is not a verdict that it is safe; it is the information to judge that with. Nothing is uploaded.

To pull apart the address itself, its query parameters and fragment, use the URL parser; to read where an email came from, the email header analyser.

questions

Why do links in my email look like this?

Email security services rewrite every link in a message so that a click passes through their servers first, where the target is checked at the moment you click. Microsoft 365 puts the real address in a url parameter; Proofpoint encodes it into its own format; others do much the same. The rewritten link is long and hides where it goes, which is exactly what you want to know before clicking.

Does decoding a link open it?

No. The real address is read out of the wrapped link itself, in your browser, so nothing is requested from the security service or the destination. That matters for a suspicious link: opening it can confirm to a sender that you read the message.

Which wrappers does it understand?

Microsoft 365 and Teams link protection, Proofpoint v1, v2 and v3, Barracuda, Symantec and Trend Micro click-time protection, and the Google, Facebook, Instagram, YouTube and Slack redirects, recognised by their own domains. A link wrapped more than once is unwrapped layer by layer. Any other site with a url= or redirect= parameter is reported as claiming a destination, since only that site decides where it really sends you. Mimecast and link shorteners keep the target on their own servers, so only opening them would tell; the tool says so.

Does a decoded link mean it is safe?

No: it means you can see where it goes. The tool points out the common tricks (a user name before an @ that looks like a site, an internationalised name with look-alike letters, a bare IP address, a direct download), but judging the destination is still up to you.

What are tracking parameters?

Additions such as utm_source, fbclid or gclid that tell a site which campaign or ad a visit came from. The page works without them, so the tool also gives the address with them removed, for sharing a clean link.