You copy a link from your address bar and paste it into a group chat. What you pasted is 180 characters long, about 90 of which describe where you came from, which campaign brought you there, and a session identifier.
Reading a URL in parts
https://shop.example.com/products/kettle?utm_source=newsletter&fbclid=IwAR2x&ref=user_8842
|_____| |______________| |_____________| |_______________________________________________|
scheme host path query
The path identifies the page. Everything after the ? is parameters, and a good proportion of them are usually removable.
A URL parser that splits a link into these components is the fastest way to see what you have, particularly for the long ones where the interesting parameter is in the middle.
The three kinds of parameter
Functional. The page needs them. A search query, a page number, a product variant. Remove these and the link breaks.
Tracking. Added by whoever sent you there, describing the campaign. These are safe to delete:
| Parameter | Added by |
|---|---|
utm_source, utm_medium, utm_campaign, utm_term, utm_content |
Analytics, usually from an email or ad |
fbclid |
|
gclid, dclid |
Google Ads |
msclkid |
Microsoft Ads |
mc_cid, mc_eid |
Mailchimp, and mc_eid identifies the individual recipient |
igshid |
That mc_eid is worth singling out. It identifies you as a specific newsletter subscriber. Forwarding a link containing it attributes every subsequent click to your email address.
Identifying. Referral codes, invite tokens, session parameters. These are the ones that matter.
URLs leak sideways
Even without sharing, a URL does not stay between you and the site.
The Referer header sends the URL of the page you were on to the page you click through to. So a secret in a URL is disclosed to the next site you visit, and this is the specific reason not to put credentials or tokens in query strings, as noted in random strings and tokens.
URLs are also written to server access logs at every hop, stored in browser history, scanned by link previewers in messaging apps, and often indexed if a page linking to them is public.
The rule that follows: an unguessable URL is a reasonable pattern for a share link with an expiry. It is not authentication.
Shortened links
A shortener replaces the destination with an opaque code, which removes your ability to read any of the above. That is the entire point of it, and it is why an unexpected shortened link deserves suspicion.
Most shorteners will reveal the target if you append + to the URL. The habit worth having is expanding before clicking rather than after.
Cleaning before you share
- Cut everything from the
?onwards and test the link. If it still lands on the right page, you are done, and this handles the majority of cases. - If it breaks, add back only the parameters the page needs.
- Look for anything that looks like a token before sharing more widely.
- Expand shortened links so you know what you are passing on.
Browsers are starting to do some of this. Firefox strips known tracking parameters in strict mode, and Safari removes some when copying. Neither is complete, and neither knows about the referral code specific to the service you are on.
The other direction
When you are producing links rather than consuming them, two things make them worth sharing.
Keep the path readable. A slug made of lowercase words and hyphens survives being pasted into a chat, an email and a document without becoming percent-encoded noise, for the same reasons that apply to file names.
And encode parameter values properly. A value containing an ampersand silently splits into two parameters unless it is percent-encoded, which is the distinction between the two JavaScript encoding functions covered in three kinds of escaping. A URL encoder settles what a value should look like before it goes into a link you publish.
Pulling every link out of a block of text, which is the usual first step when auditing an email template or a page of content, is what URL extraction is for. All of these run in the tab, which matters because the links people paste into online parsers are frequently the ones carrying a token.