A custom HTML tag is a Google Tag Manager tag type that places whatever HTML or JavaScript you paste into it onto the page, so you can run code for which Tag Manager has no ready-made template. It is the most flexible tag in Tag Manager and, for exactly that reason, the one most likely to cause problems.
How a custom HTML tag works
Most tags in Tag Manager are built from templates. You choose “Google Analytics: GA4 Event” or a vendor’s template, fill in a few fields, and Tag Manager writes the code for you. A custom HTML tag skips that step. The code you paste, usually a script supplied by a software vendor, is inserted into the page whenever the tag’s trigger fires.
Because it runs directly in the page, that code can do anything the site’s own code can do: read cookies, read form fields, change content and load further scripts from other domains. Tag Manager does not check what it does. Beneath the code box sit a few options, such as support for older scripts that use document.write, and the usual firing triggers, blocking triggers, consent settings and tag sequencing apply as they would to any tag.
Why it matters
Custom HTML tags are how many businesses add a review widget, a live chat script, call tracking number swaps or a smaller ad network’s pixel. That is useful, but each one is third-party code running on your site with full access, and it is easy to forget it is there. For a UK business there are three specific risks:
- Consent. Google’s own tags have built-in consent checks. A custom HTML tag has none. Unless you require additional consent in its consent settings, or gate it with a trigger tied to your consent platform, it may set cookies before the visitor agrees, which breaches PECR.
- Personal data. A pasted script can read form fields, including names and email addresses, and send them elsewhere. Under UK GDPR you are responsible for that transfer whether or not you knew it was happening.
- Speed and stability. Each script adds weight and network requests, which can harm Core Web Vitals, and an error in one script can stop other code on the page from running.
Where a vendor offers a custom template in the Community Template Gallery, I would use it instead. A template declares up front which cookies it reads and which domains it contacts, and Tag Manager holds it to that list.
Common mistakes
- Pasting Google code into a custom HTML tag. Adding the GA4 or Google Ads snippet this way, rather than using Google’s own tag types, loses the built-in consent handling and often double counts.
- Firing on all pages when one is enough. A chat script needed on the contact page does not have to load on every blog post.
- Leaving old tags live. A pixel from an ad network you tried years ago still runs, still sets cookies and still slows the site.
- No owner or note. Months later nobody knows what “Custom HTML 4” does or whether it is safe to remove.
- Wide publishing rights. Anyone who can publish the container can put any code on your site. Keep publish access to the people who need it.
How to act on it
Open your container, filter the tag list by type and review every custom HTML tag. For each one, note what it does, who asked for it and whether it is still needed. Pause anything nobody can explain, and remove it once you are sure nothing depends on it.
For the tags that stay, check whether a template now exists and switch if it does. Set consent requirements on the rest, limit their triggers to the pages that need them, and test in preview mode with cookies declined first, to confirm nothing fires that should not. Use consent mode for Google’s tags and your consent platform’s signals for everything else. If your container has grown untidy, a review like this is part of the tracking setup I carry out for performance marketing work.