Scan Any GTM Container in 10 Seconds
Every published GTM container has a public JavaScript endpoint. Google serves it at www.googletagmanager.com/gtm.js?id=GTM-XXXXXX, and the file contains the container's runtime representation: tags, triggers, variables, consent settings, and GA4 configuration. It's how GTM works. The browser downloads this file on every page load, parses it, and executes the container's logic.
The container ID itself is visible in the source code of any page that uses GTM. View source, search for "GTM-", and you'll find it. This is by design. Google's own support forums confirm that the container ID is inherently public and that trying to hide or obfuscate it isn't practical.
TagManifest now accepts a GTM container ID directly. Enter GTM-XXXXXX, and the tool fetches the public endpoint, parses the runtime representation, and runs the same scanner pipeline as a JSON export. No file upload required.
What the public endpoint contains
The gtm.js file is a compiled representation of the container, not the container export. It contains enough for structural analysis: tag types, trigger configurations, consent settings, GA4 measurement IDs, and the general architecture of the container. It doesn't contain Custom HTML source code, variable definitions, or folder structure, because those are only available in the full JSON export from the GTM admin interface.
This means a URL scan gives you a meaningful but partial view. Consent enforcement, GA4 configuration, tag inventory, and structural health are all assessable. Custom HTML code review, variable audit, and organizational assessment require the full export. The scan page makes this clear: here's what we can check from the public endpoint, here's what requires a JSON export for the full picture.
Quick checks, prospecting, and second opinions
Quick checks. Before a client call, scan their container ID. In the time it takes to open the GTM admin, request access, and find the workspace, you already have a consent overview, tag inventory, and health score.
Prospecting. Agencies and consultancies can scan a prospect's container before a discovery call. The scan won't reveal everything, but it surfaces enough to ask informed questions: "I noticed your container has 34 tags but no consent infrastructure. Is that something you're aware of?" That's a different conversation than "tell me about your analytics setup."
Second opinions. Someone sends you a GTM container ID and asks "is this in good shape?" You can answer in 10 seconds instead of asking for admin access and waiting for an invite.
Team reviews. Marketing operations teams managing multiple containers can spot-check without switching between GTM accounts. Enter the ID, see the overview, move on.
What "public" means for your container
The gtm.js endpoint is standard Google infrastructure. Every page that loads GTM sends a request to this endpoint, every visitor to your site downloads your container's runtime code, and browser developer tools show the full request. There is nothing private about the container's compiled output.
If that makes you uncomfortable, it's worth considering server-side GTM. In a server-side configuration, the container logic executes on your server rather than in the visitor's browser. The client-side component becomes a lightweight data collection script, and the full container logic (including tag destinations, consent handling, and data transformation) runs in an environment you control. The public endpoint still exists for the client-side container, but the sensitive logic lives server-side.
For most organizations, the public endpoint isn't a security concern. It reveals your tag inventory and measurement configuration, not your tracking data, customer information, or conversion metrics. An auditor (or a competitor) can see that you use GA4, run Google Ads remarketing, and have a Meta pixel. They can't see your data.
The value of public endpoint scanning is speed and accessibility. No accounts, no permissions, no file exports. Enter an ID, get a scan.