Allow Custom HTML tags only after the built-in and community templates have been ruled out, and send each one through review. A Custom HTML tag is code from a vendor, pasted into your container and run in every visitor's browser. Google itself advises using built-in templates to avoid performance and malware issues.
What a Custom HTML tag is
Google's Tag Manager help describes the Custom HTML tag as a way to deploy a tag that is not yet supported natively. The code is supplied by the tag vendor, and you paste it in. It can be any JavaScript wrapped in script tags, and it can use variables from your container.
That flexibility is the risk. The tag has the same powers as any other script on the page. For what scripts can reach, see what a third party script can do on your page.
The four tag types, from safest to riskiest
| Type | What it is | Risk level |
|---|---|---|
| Built-in tag template | Maintained by the platform | Lowest |
| Community template | Shared by others, sandboxed JavaScript | Low to medium, review the template |
| Custom Image tag | Fires a pixel from a URL | Medium, data goes in the URL |
| Custom HTML tag | Arbitrary code | Highest |
Google recommends Sandboxed JavaScript for custom code formatting where it applies, and the help page points to the Community Template Gallery for many more templates.
A simple policy
- Template first. Ask whether a built-in or community template exists before writing custom code.
- Vendor source required. Every Custom HTML tag must name the vendor, the page where the snippet came from, and the business purpose.
- No loaders you cannot read. If the snippet only loads another script from the vendor, note that the real code can change after your review, and decide if you accept that.
- Narrow triggers. Fire on the pages that need it, not on all pages.
- Review before publish. Use the version diff. The routine is in reviewing tag manager changes like code.
- Expire it. Put a review date on the tag. If nobody claims it, remove it.
What breaks with a strict CSP
If you run a strict Content Security Policy, Custom HTML tags are where friction shows up. Google's CSP guide for tags notes that Custom JavaScript variables evaluate to undefined without 'unsafe-eval', and recommends Custom Templates as the alternative. Choosing templates helps both security and policy.
Who decides
The question is less about banning and more about routing. Marketing keeps speed for templates, and a named reviewer takes custom code. A one page request form is often enough: vendor, purpose, pages, data read, owner, review date.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how each component gets an owner and a version, then ask whether each of your custom tags has the same.
Where Safeguard fits
Safeguard's SBOM and dependency scanning list the packages in your code. Tag manager contents are outside that, so keep the tag list as a separate inventory. A free scan covers the repository side.
Quick check
Is a Custom Image tag safer than Custom HTML?
It does less, because it only requests an image URL, but the URL can carry data to a third party, so it still needs an owner and a purpose.
Do templates remove all risk?
No. They narrow what code can do, but you still review the template and what data it sends.
Sources
- Google Tag Manager Help: custom tags
- Google tag platform: CSP guide
- OWASP Third Party JavaScript Management Cheat Sheet
Last reviewed: 19 October 2026.
