Understanding URL Parameters and Tracking Codes

Why URL parameters matter

Click a link in a marketing email or an ad and look at your browser's address bar. You'll often see the normal web address followed by a question mark and a long string of extra text, something like ?utm_source=newsletter&fbclid=IwAR3x….

That extra text is made of URL parameters, also called the query string. Some parameters change what the page shows you, such as search terms or filters. Others quietly record where you came from, so a business can tell which email, ad or post brought you there.

Understanding parameters helps marketers measure campaigns properly, helps developers build websites safely, and helps everyone else see what a link is really carrying, and tidy it up before sharing. This guide covers all three, explaining each term along the way.

The anatomy of a URL

A URL (Uniform Resource Locator) is a web address. It's made of several parts, each with its own job:

https://shop.example.com/products?colour=red&size=M#reviews
└─┬──┘   └──────┬───────┘└──┬────┘└────────┬───────┘└──┬───┘
scheme        host        path       query string   fragment

The query string starts with a ?. Each parameter is a key=value pair: a name (the key) and its setting (the value), joined by =. Pairs are separated by &. So colour=red&size=M contains two parameters: colour is red and size is M.

Functional and tracking parameters

Parameters fall into two broad groups.

Functional parameters

These change what the page shows. Remove them and you get a different result:

https://store.example.com/search?q=running+shoes&page=2&sort=price_asc&min_price=50

Here, q is the search term, page is the page of results, sort is the order, and min_price is a filter.

Tracking (informational) parameters

These don't change the page at all. They simply carry information about where the visit came from, which analytics software on the page records:

https://store.example.com/search?q=shoes&utm_source=google&utm_campaign=brand_kw

Remove the utm_ parameters and the search results are identical. The difference only shows up in the business's reports.

This distinction matters when you clean up a link before sharing it: tracking parameters can usually be removed safely, but removing a functional one can break the link or change what people see.

UTM tracking parameters

UTM stands for Urchin Tracking Module, named after Urchin Software, the web analytics company Google bought in 2005 and turned into Google Analytics. UTM parameters have become the standard way to label campaign links, and almost every analytics tool understands them.

Strictly speaking, analytics tools will accept a link with only some of these, but using source, medium and campaign every time keeps reports tidy and comparable.

A real-world example

A retailer sends a newsletter about its summer sale. The "Shop now" button might link to:

https://shop.example.com/summer-sale
  ?utm_source=newsletter
  &utm_medium=email
  &utm_campaign=summer_2026
  &utm_content=hero_cta_button

(It's split over several lines here for readability; a real link is one continuous line.) When someone clicks, the analytics tool records those values. If they later buy something, the sale can be credited to newsletter / email / summer_2026, and even to that specific button.

Links like this are long and messy, which is one reason marketers shorten them before sharing.

UTM habits that keep data clean

• Always lowercase, every time.
• No spaces. Pick either hyphens (summer-sale) or underscores (summer_sale) and stick with it.
• Use a builder, such as Google's Campaign URL Builder or a shared spreadsheet, rather than typing links by hand.
• Keep a register of every campaign link and its values.
• Never tag internal links (links between pages of your own site). They overwrite the visitor's original source, so a visit that came from Google suddenly looks as if it came from your own homepage banner.

Click IDs and other tracking codes

Alongside UTMs, many platforms add their own parameters automatically. The most common are click IDs: long, unique codes that identify a single click, so an advertising platform can later match a purchase or sign-up back to the ad that caused it.

A typical click ID looks like this:

https://example.com/page?fbclid=IwAR3xQkR7...

Website owners can't stop platforms adding these, but they don't need to show up in reports as separate pages; most analytics tools handle the well-known ones automatically.

Testing and feature flags

Developers also use parameters to force a particular version of a page during a test, or to switch on a feature that's still being built:

https://app.example.com/?variant=B&feature_flag=new_checkout

These are handy, but anything that unlocks unfinished features should also be protected by proper permissions, since anyone can type a parameter into the address bar.

Reading, building and encoding parameters in code

This section is for readers who write code. If that's not you, feel free to skip ahead to privacy and security.

JavaScript in the browser

The built-in URLSearchParams tool reads query strings without any fiddly text handling:

// Page address: https://example.com/page?utm_source=email&discount=SAVE20
const params = new URLSearchParams(window.location.search);

params.get('utm_source');   // "email"
params.get('discount');     // "SAVE20"
params.get('missing_key');  // null (not present)
params.has('discount');     // true

// Loop through every parameter
params.forEach((value, key) => {
  console.log(`${key} = ${value}`);
});

// Convert to a plain object
const obj = Object.fromEntries(params);
// { utm_source: "email", discount: "SAVE20" }

Building a URL with parameters

const url = new URL('https://example.com/page');
url.searchParams.set('utm_source', 'newsletter');
url.searchParams.set('utm_campaign', 'launch_2026');

console.log(url.href);
// "https://example.com/page?utm_source=newsletter&utm_campaign=launch_2026"

Node.js on the server

The same URL class is available globally in Node.js, so there's nothing to import:

const url = new URL('https://example.com/page?utm_source=email&discount=SAVE20');
url.searchParams.get('utm_source');  // "email"
url.searchParams.get('discount');    // "SAVE20"

Python on the server

from urllib.parse import urlparse, parse_qs

raw_url = "https://example.com/page?utm_source=email&discount=SAVE20&tags=a&tags=b"
params = parse_qs(urlparse(raw_url).query)

# parse_qs always returns lists, because a key can appear more than once
params["utm_source"]   # ['email']
params["tags"]         # ['a', 'b']

# Get the first value safely
source = params.get("utm_source", [None])[0]

URL encoding

Only certain characters are allowed in a URL. Anything else, such as spaces, accented letters or characters with special meaning, must be percent-encoded (also called URL encoding): replaced by a % and a two-digit hexadecimal (base-16) code. Non-English characters are first converted to UTF-8, the standard way of storing text as bytes, so they become several codes.

encodeURIComponent('hello world & more');
// "hello%20world%20%26%20more"

decodeURIComponent('hello%20world%20%26%20more');
// "hello world & more"

// URLSearchParams encodes automatically
const p = new URLSearchParams();
p.set('q', 'café & croissant');
p.toString();  // "q=caf%C3%A9+%26+croissant"

Use encodeURIComponent() for individual values, not encodeURI(). The latter leaves & and = alone, which breaks the structure of a query string.

Privacy, security and browser changes

URLs are recorded everywhere

A full URL, parameters included, ends up in browser history, server logs, analytics tools, and sometimes in the systems of whoever runs the network you're on. So sensitive information must never go in a URL: no passwords, login tokens, API keys, card numbers or health details. Send these in the body of a request over HTTPS instead (for example, a form submitted with the POST method), where they aren't stored in history or logs by default.

Referrer leakage

When you follow a link from one site to another, your browser normally tells the new site where you came from, in a piece of information called the Referer header (the misspelling is historic and official). In the past this often included the full previous URL, parameters and all.

Modern browsers now default to a safer rule called strict-origin-when-cross-origin: other websites are told only the domain you came from, not the full page address or its parameters. Site owners can set this explicitly, or make it stricter, with an HTTP header:

Referrer-Policy: strict-origin-when-cross-origin

For individual links, adding rel="noreferrer" sends no referrer information at all.

Browsers stripping tracking parameters

Some browsers now remove well-known click IDs automatically, though usually only in certain modes:

• Safari (on recent Apple devices) removes click IDs such as gclid, fbclid and msclkid in Private Browsing and from links opened in Apple's Mail and Messages apps. It doesn't remove them in normal browsing by default, and it leaves UTM parameters alone.
• Firefox removes a list of known tracking parameters when its Enhanced Tracking Protection is set to Strict.
• Brave strips known tracking parameters by default.

These rules keep changing, so marketers shouldn't rely on click IDs alone. UTMs, consented first-party data (information customers give you directly) and server-side tracking all help fill the gaps.

Open redirect vulnerabilities

A common website security flaw is an open redirect: a page that sends visitors to whatever address is given in a parameter, without checking it. Scammers love these, because the link starts with a trusted domain:

# Dangerous: sends people anywhere
https://example.com/login?redirect=https://scam-site.example/fake-login

# Safer: only accept relative paths on your own site, checked against an allowlist
https://example.com/login?redirect=%2Fdashboard

Privacy law and consent

Using click IDs or other identifiers to profile people or target them with ads can bring privacy laws into play. Under the EU's GDPR, for example, this kind of tracking generally needs consent, and Australia's Privacy Act sets its own rules for handling personal information. Requirements depend on where your users are, so check with a privacy professional if you're unsure.

Best practices

For marketers

• Agree on a UTM naming guide before your first campaign, and share it.
• Generate links with a builder or template, not by hand.
• Click-test every tracked link before sending it to a big audience.
• Check your analytics regularly for oddly spelled or duplicate sources.
• Shorten long tracked links with a branded shortener before publishing them.
• Never put UTMs on links between your own pages.

For developers

• Use URLSearchParams, URL or a well-tested library, never hand-made text splitting.
• Treat every parameter as untrusted input: validate and clean it before use.
• Keep sensitive data out of URLs entirely.
• Check redirect parameters against an allowlist to prevent open redirects.
• Set a sensible Referrer-Policy.
• Exclude tracking parameters from canonical URLs (see below).

Canonical URLs and search engines

Search engines may treat /shoes, /shoes?colour=red and /shoes?utm_source=facebook as three different pages with the same content, splitting their ranking signals. A canonical tag tells them which address is the "main" one:

<!-- In the <head> of every variant of the page -->
<link rel="canonical" href="https://example.com/shoes">

Google retired its old URL Parameters setting in Search Console in 2022, so canonical tags and consistent internal links are now the main way to guide it.

Quick reference glossary

Wrapping up

URL parameters look like random clutter, but they run much of the modern web: searches, filters, campaign tracking, ad measurement and testing. Knowing what each part does lets you measure campaigns accurately, build safer websites, and share cleaner links.

If you remember four things, make them these:

1. Everything after ? is parameters: some change the page, others only track where you came from.
2. Use consistent, lowercase UTM values, and never on internal links.
3. Never put sensitive information in a URL, and treat every parameter as untrusted input.
4. Browsers increasingly strip click IDs, so don't rely on them alone.

Next time you see a long link, take a look after the question mark. You'll know exactly what it's telling you.