A UTM tracking link is an ordinary web URL extended with five standardized query parameters — utm_source, utm_medium, utm_campaign, utm_term, and utm_content — that describe where a click came from so analytics tools can group traffic by campaign. Building one means starting with a complete http or https destination URL, filling in values for the three required fields (source, medium, and campaign), optionally adding term and content when they help reporting, then copying the finished link for use in an ad, email, social post, or QR code. A focused tool such as the UTM Link Builder handles that sequence in the browser: it parses the destination URL, keeps the path, fragment, and any unrelated parameters, removes only existing copies of the five UTM keys it owns, then appends the values you typed. The result is a single, ready-to-paste campaign URL with no manual query-string editing and no spreadsheet in the loop.
The five UTM keys are the traditional manual-tagging fields described in Google Analytics guidance and have stayed the same across property versions, which is why the term "traditional" still applies when a builder advertises its scope. Three of the five — source, medium, and campaign — are the minimum needed for the traffic-source dimensions to populate correctly in a standard campaign report.
What Goes Inside a UTM Tracking Link
Each UTM key answers a single question about the click. utm_source identifies the specific site, app, or publication that referred the visit. utm_medium describes the marketing channel type, such as cpc, email, social, or affiliate. utm_campaign names the campaign itself, usually tied to a launch, a promotion, or a flighted initiative. utm_term and utm_content are optional refinements: term is most often used for paid keywords, and content is most often used to differentiate links or creatives that share the same source, medium, and campaign.
The five values are stored as ordinary query parameters, so a finished link looks like a normal URL with a tail of key-value pairs. Because they live in the URL itself, they travel with the click, survive most redirects, and appear in the browser address bar, the referrer header, and the analytics request that follows.
| Parameter | What it describes | Required | Typical value |
|---|---|---|---|
| utm_source | Where the traffic came from | Yes | google, newsletter, partner-blog |
| utm_medium | Marketing channel type | Yes | cpc, email, social, affiliate |
| utm_campaign | Specific campaign name | Yes | spring-launch, black-friday-2026 |
| utm_term | Paid keyword (legacy) | No | running+shoes |
| utm_content | Differentiates similar links or creatives | No | header_banner, version_a |
Any builder that claims to be a UTM tool should, at minimum, manage these five keys and nothing else. Tools that quietly inject extra analytics parameters make it harder to compare link reports across platforms, so the narrower the scope, the easier the audit.
Set a Naming Convention Before You Generate the Link
The fastest way to ruin a UTM program is to let every teammate type values ad hoc. A link tagged with utm_source=Google and another tagged with utm_source=google will show up as two separate sources in your traffic report. Pick a casing rule (lowercase is the most common), a separator (a hyphen is friendlier to URL encoding than a space), and a small vocabulary for each channel, then share it before anyone generates a campaign link.
Use labels that describe the placement, not the person who built the link. A source like newsletter, a medium like email, and a campaign like march-features is far more useful in a report than a person's first name, an internal handle, or a vanity slug. Query parameters travel through browser history, referrer logs, analytics tools, and shared links, and any value you put in a UTM key can end up in places you do not control. Avoid names, email addresses, phone numbers, account numbers, or anything that could identify a specific person.
Keep a campaign record outside the link itself — a spreadsheet row, a project note, or a brief in your marketing tool. The link should describe the placement; the record should describe the goal, the audience, and the dates.
Build a UTM Tracking Link in Three Steps
The UTM Link Builder runs entirely in the browser. It does not send your destination URL or your campaign labels to a server, and it does not validate your analytics setup. It simply parses the URL, applies the five managed keys, and shows you the result.
- Paste the complete http or https destination URL. Use the full landing page address, including the path. If the page already has unrelated query parameters — a ref value, a gclid, a language switch, or an internal app id — keep them. If it has a #fragment for in-page navigation, keep that too.
- Enter campaign source, medium, and name; add term or content only when needed. utm_source, utm_medium, and utm_campaign are required. utm_term and utm_content are optional: if you leave them blank, the builder simply does not add them, which keeps the link shorter and avoids accidental empty values in your reporting.
- Build the URL, review the preserved parameters and fragment, then copy the result. Inspect the output to confirm the path and any non-UTM parameters are still where you expected them. Spaces in a value are encoded into a valid URL form automatically. Copy the finished string and paste it into your ad, email, social post, partner placement, or QR code.
If you need to update a live campaign, paste the existing campaign link back into the builder, change only the values that need to change, and rebuild. The builder removes the old copies of the five UTM keys it owns and appends the new ones, while leaving the rest of the URL exactly as it was.
Refresh an Existing Campaign Link Without Losing Other Parameters
Most landing pages already carry parameters that the marketing team did not add — a session id, a referrer id, a tracking id from the ad platform, or a query string the engineering team uses to toggle a feature flag. A safe refresh of a campaign link needs to keep those parameters in place while replacing the UTM portion. Doing that by hand in a text editor is error-prone: a missing ampersand or a misplaced question mark silently breaks the URL.
The UTM Link Builder solves that problem in a specific, narrow way: it deletes only utm_source, utm_medium, utm_campaign, utm_term, and utm_content, and leaves every other query key, the path, and the #fragment untouched. That means you can paste a long production URL, change just the campaign fields, and get back a clean refreshed link whose unrelated parameters are exactly where they were before. For a deeper walk-through of this preservation behavior, see the guide on how to create UTM links without breaking existing tags.
This narrow-scope behavior is also why the builder fits a repeatable workflow: paste, edit five values, copy. Nothing is uploaded, no spreadsheet template is required, and the same link can be regenerated a year later from the same destination URL.
Inputs the Builder Will Not Accept
Because the tool is scoped to web campaign destinations, a small number of inputs are rejected up front. Relative paths such as /pricing are not valid on their own — a complete address including the scheme and host is required, so the result is a usable campaign URL. Email links (mailto:), file-transfer links (ftp:), and other non-web protocols are outside scope. URLs that carry username or password credentials are refused because embedding credentials in a campaign link is rarely what you want, and the browser URL API will normalize them away in any case.
Signed or pre-signed URLs are explicitly not supported. The browser URL API normalizes query encoding during parsing, and that normalization can invalidate the signature. If your destination is a signed link — for example, a temporary download URL from a cloud bucket — start from an ordinary destination URL instead and add tracking on the page that the signed URL resolves to.
None of these limits is a judgment about your workflow. They exist because a builder that promises to handle every URL format also tends to silently mangle the ones it does not recognize. Sticking to plain http or https web addresses keeps the contract simple and the output predictable.
Test the Finished Link Before You Publish It
The builder constructs a URL. It does not, and cannot, confirm that your analytics property exists, that auto-tagging is active, that a redirect in your chain preserves the parameters, that the destination page loads, or that future traffic will appear in a specific report. Treat the output as a string you can paste anywhere; treat the tracking confirmation as a separate step.
A practical test routine is short. Open the finished link in a private browser window and watch the address bar — you should see all five values (or the three you kept) encoded in the query string. Then make a small visit to the link from the channel you plan to use, wait the typical processing window for your analytics tool, and check that the traffic-source dimensions are populated the way you expect. Keep a record of the URL alongside the campaign notes so you can trace a report row back to the exact link that produced it.
If you need a short public-facing URL, generate the UTM link first and pass it to a trusted redirect or short-link service only after you have confirmed that the service preserves the full query string. Many shorteners strip parameters or rewrite them, which defeats the purpose of the tags. The local builder keeps the construction step quick and explicit, and it leaves the testing, the shortening, and the channel-specific decisions to you.