What's the difference between a Custom HTML tag and a custom template?

A Custom HTML tag runs arbitrary script with few restrictions and no defined input fields - fast to write, hard to govern at scale. A custom template defines a proper UI with named fields, runs inside GTM's sandboxed APIs instead of raw JavaScript, and can be reused across tags without anyone needing to read or edit code each time.

Why can't my custom template do something a normal script could?

Templates run inside a sandboxed permission model - they can only call the specific APIs the template explicitly requests permission for (like injectScript or sendPixel), and each permission is visible to whoever reviews the template before approving it. This is a deliberate security boundary, not a missing feature - unrestricted script access is exactly what Custom HTML tags already provide, with correspondingly less oversight.

Do custom templates need to be published to the Community Template Gallery?

No - a template can be built and used privately within a single container without ever being submitted to the gallery. Publishing to the gallery is only necessary if you want other GTM users outside your own container to be able to import it.

Webclat / GTM Practice / guides

Custom templates in Google Tag Manager

When no gallery template covers a vendor, and Custom HTML has grown into something nobody wants to touch, a custom template turns raw script into a governed, reusable tag with named fields.

Quotable summary

A custom template packages a tag or variable's logic into a defined UI with named fields, running inside GTM's sandboxed API surface instead of unrestricted JavaScript. Build one when a vendor has no gallery template, when the same data-layer transformation gets copy-pasted across multiple Custom HTML tags, or when a third-party install needs to be standardized so non-developers can configure it safely without touching code.

Custom HTML vs a real template

A Custom HTML tag is the fastest way to get arbitrary script running, but it has no defined inputs, no built-in permission review, and becomes progressively harder to reuse or hand off as it grows. A custom template solves the reuse and governance problem: it defines specific fields (a pixel ID, an event name, a currency), runs the logic through GTM's sandboxed template APIs, and shows up in the tag list looking exactly like a native, first-party tag type.

When to build one

A vendor with API/pixel integration instructions but no Community Template Gallery listing
The same data-layer transformation logic copy-pasted across several Custom HTML tags - a template centralizes it in one place
Standardizing a third-party pixel install across multiple brand containers so every implementation stays consistent
Letting a non-developer configure a tag safely through named fields, instead of editing raw script

The sandbox model

Templates don't get unrestricted JavaScript access. They call a defined set of sandboxed APIs - things like injectScript, sendPixel, or copyFromDataLayer - and each one the template uses must be explicitly requested and is visible to whoever reviews or approves the template before it's used in a live container. This is a deliberate security boundary: it's what makes a custom template safer to hand to a less-technical teammate than an open Custom HTML tag, and it's also what occasionally blocks a technique that would work in plain JavaScript.

A template's permission list interacts directly with Content Security Policy - if a template needs to load an external script, that script's host generally still needs to be allowed by the site's CSP. See our CSP-blocking-GTM QA page if a custom or gallery template stops working after a CSP change.

Testing a custom template

The template editor includes a built-in test harness (the "Preview" tab inside the template editor itself, separate from container Preview mode) where you can simulate field inputs and inspect console output before ever adding the tag to a live workspace. Test there first, then add the tag to a real workspace and confirm it in container Preview mode before publishing, same as any other tag.

Common questions

What's the difference between a Custom HTML tag and a custom template?
A Custom HTML tag runs arbitrary script with few restrictions and no defined input fields - fast to write, hard to govern at scale. A custom template defines a proper UI with named fields, runs inside GTM's sandboxed APIs instead of raw JavaScript, and can be reused across tags without anyone needing to read or edit code each time.
Why can't my custom template do something a normal script could?
Templates run inside a sandboxed permission model - they can only call the specific APIs the template explicitly requests permission for (like injectScript or sendPixel), and each permission is visible to whoever reviews the template before approving it. This is a deliberate security boundary, not a missing feature - unrestricted script access is exactly what Custom HTML tags already provide, with correspondingly less oversight.
Do custom templates need to be published to the Community Template Gallery?
No - a template can be built and used privately within a single container without ever being submitted to the gallery. Publishing to the gallery is only necessary if you want other GTM users outside your own container to be able to import it.

A Vendor Install That Doesn't Fit Any Gallery Template?

We build the custom template, define its permissions deliberately, and test it before it ever touches a live container.

Get a Custom Template Built