UTM checker
Paste a batch of campaign URLs, one per line. We check each one for missing UTMs, casing and whitespace slips, duplicate keys, and parameters stuck in the fragment - then compare them all for the inconsistencies that only show up across a set. Runs entirely in your browser.
One URL per line. Parsing happens entirely in your browser - nothing is uploaded, logged, or sent anywhere.
Paste one or more campaign URLs above to see the report.
How to read a UTM audit before a campaign goes live
- 01
Paste every URL you are about to launch
One line per URL - the tracking links from every ad, email, and post in the campaign, not just one sample. The cross-URL checks only work once there is a batch to compare.
- 02
Fix the errors first
A missing utm_source, utm_medium, or utm_campaign, and any UTM parked in the URL fragment after a #, mean the click shows up in analytics with a gap, or not at all. Nothing else here is worth doing before those are clean.
- 03
Resolve the warnings before you print or schedule anything
Uppercase letters, stray whitespace, a repeated key, and mixed + / %20 encoding all still work when you click the link, which is exactly why they survive into production - the damage only shows up afterward, in the analytics report.
- 04
Read the batch section, not just the per-URL rows
A single URL can pass every per-URL check and still collide with another one in the set: the same campaign spelled two ways, or the exact same link pasted twice. That is what the cross-URL section is for.
What the checks are actually protecting you from
Case differences split one campaign into two rows
GA4 and most analytics tools compare UTM values literally, not case-insensitively. newsletter, Newsletter, and NEWSLETTER are three different sources as far as the report is concerned, even though a human reads them as one campaign - the single most common cause of a campaign's numbers looking smaller than they are.
A utm_medium GA4 does not recognize
GA4's default channel grouping maps a fixed list of medium values - cpc, organic, referral, email, affiliate, and a handful of others - onto a channel. Invent a value outside that list (social-media instead of social, partner instead of affiliate) and the traffic lands in Unassigned or (Other), which drags down every channel report even though the volume is fine.
Tracking parameters that survive onto the canonical URL
If the destination page's canonical tag is not set to the clean URL without query parameters, a tagged link can get indexed as if it were the real page. Confirm the canonical is self-referencing and stripped of UTMs before a tagged link goes into paid distribution or a widely shared post.
UTMs on your own internal links overwrite the real source
A visitor arrives from a newsletter and the session correctly records utm_source=newsletter, then clicks a nav link on your own site that happens to carry UTM parameters - the source is overwritten to whatever that internal link says. Only tag links that bring someone in from outside; never tag a link between two of your own pages.
Questions people ask about auditing UTM parameters
Why does this tool flag uppercase letters as a problem, not just a style nitpick?
Because most analytics tools, GA4 included, compare UTM values as literal strings. Newsletter and newsletter are not normalized to the same value - they are two separate rows that both represent the same real campaign, and the split is silent until someone notices the numbers do not add up.
What counts as a paid medium for the utm_term / utm_content check?
Values like cpc, ppc, display, paidsocial, affiliate, and similar - the mediums GA4's default channel grouping treats as paid. utm_term and utm_content exist to identify a paid keyword or creative variant; on an email or organic link they usually mean the field is being used as a free-text note instead, which is worth flagging but is not wrong on its own, hence an info-level finding, not an error.
Why is a UTM parameter after a # treated as an error instead of a warning?
Because it is not a slip that degrades a report - it is a parameter no analytics collector will ever see. Everything after # is the URL fragment, which browsers keep client-side and never send in the HTTP request. A single-page app that builds share links from its own hash-based routes is the most common place this happens by accident.
Does this tool check whether the destination page actually exists?
No - it only parses the text you paste, using the browser's own URL and URLSearchParams, and never makes a network request. For a live check of where a link actually goes, use the link checker; for how a URL renders as a social preview, use the OG checker.
Can tagged URLs hurt SEO?
Not if the destination declares a canonical URL without the tracking parameters, which is the normal setup - search engines then treat the tagged and untagged versions as the same page. The risk is not ranking, it is a tagged URL getting indexed anyway because the canonical tag was missed - worth checking once per destination, not once per campaign.