See Inside Any GTM Container Without Access

Q: Can I see a GTM container without being added to the account?

Yes, the published version. Google serves it as gtm.js to every browser that loads the site, so its tags, triggers and variables are readable from the container ID alone. Workspaces, drafts and version history stay inside the account.

You inherit a client whose previous agency left no access. You are asked to audit a site before anyone has signed anything. Someone insists the purchase tag is live and you would like to know without waiting two days for an invitation. Or you simply want to see how a site you admire has wired its tracking.

All four have the same answer, and it does not need a login: the container is already public. It has to be — a browser cannot run tags it was not sent.

The container is already on your machine

A GTM snippet loads googletagmanager.com/gtm.js?id=GTM-XXXXXXX. That file is the published container, compiled. Inside it is one object, resource, with four lists that together are the whole setup:

macros — the variables: every Data Layer Variable name, lookup table and Custom JavaScript.
tags — each tag's type and fields: measurement IDs, conversion IDs and labels, event parameters, the body of every Custom HTML tag.
predicates — single conditions, such as {{Event}} equals purchase.
rules — which conditions fire, and which block, which tags.

The Container tab of Tag Master with GTM-DEMO123 typed in and opened: the header says it contains 16 tags at version 10, above boxes for 16 tags, 12 triggers and 22 variables, a filter field and tag-type chips for Google Ads conversion and remarketing. — A container read from its ID alone. The counts are the published version; none of the names you would see in GTM are here, because GTM never sends them.

Nothing here needs access to the account, because nothing here is secret: it is what the site sends every visitor. Tag Master fetches that file with the container ID as the only thing in the request, and reads it as text. None of its code is run.

Reading it by hand

Open the URL above with a real ID and search the text. GA4 event tags are __gaawe, Google Ads conversions __awct, Custom HTML __html, and anything built from a community template starts with __cvt_. Conditions refer to variables by position in the macros list, and rules refer to conditions and tags by position too.

That is workable for a container with five tags. At two hundred, following index numbers across four lists is an afternoon, and the answers you want — which trigger fires the purchase tag, what it sends, whether it waits for consent — sit three lookups apart.

Reading it in Tag Master

Open the Container tab in the side panel.
Type the ID and press Open. On the site itself, Find this site's GTM container reads the page's script tags once and fills it in — without switching the site on, and without anything leaving the browser.
The header gives the container's published version and how many tags, triggers, variables and templates it holds, with a Checks count for problems found in the file itself.
Open any tag and it reads like GTM's own screen: Tag Configuration with the fields under their GTM names, then Triggering. Every trigger and every {{variable}} in it is a link to that item.

Because the names are not published, nine Google Ads conversion tags would otherwise be nine identical rows. Each is named after the trigger that fires it instead — Google Ads conversion — purchase. Listeners GTM adds on its own and trigger groups are set aside unless you ask for them; in one real container of 228 tags, 118 were exactly that.

What the file says that nobody reads

Some fields in gtm.js matter a great deal and are invisible from the page:

Consent settings. Which tags wait for which consent type. In a real container of 228 tags, 73 did. In Europe that is the difference between a tag that failed and a tag that was never permitted to run.
Sequencing and priority. Setup and cleanup tags, linked in both directions.
Trigger groups. Which triggers make up each group, and which groups each trigger belongs to.
Zones. A container that loads other containers, with the IDs it loads and the conditions it loads them under. The IDs of loaded containers are the only names GTM publishes, and each opens with one click.
Custom template permissions. Which addresses a template injects scripts from and which globals it touches. That is how the Meta, TikTok, LinkedIn or consent-platform templates are recognised by name even though the file never says which gallery template they came from.

The Checks section reads the container as a whole: tags no trigger fires, paused tags, tags waiting for consent, Custom HTML that loads a remote script or calls document.write, two tags configuring the same ID, and variables nothing reads.

Where the file stops

Names, folders and notes. Account-only, as above.
Paused tags. They are listed, but GTM does not publish their settings, so the configuration card says it is empty for that reason rather than looking broken.
Drafts. Only the live version is served. A workspace nobody has published is not in the file — that is what Preview is for.
Server containers. Their configuration never reaches a browser.
Whether a trigger fires here. The file describes what the setup would do, not what it did. On the site you are debugging, triggers whose event arrived in your session are marked event seen — not "fired", because the trigger's conditions are a separate question. A container read from another site is never compared with this page's events.
Other pages. The answer to "which container" belongs to a page, not a domain. Storefront and checkout often load different ones.

If Google ever declines to serve the file to a direct request, the panel takes a pasted copy of the gtm.js text or a GTM export instead.

The GA4 property behind it

The same tab reads a GA4 measurement ID from gtag/js, which carries settings that normally need Admin access: Enhanced Measurement, key events, cross-domain linking and the session timeout. When the file does not carry a setting, the panel says so rather than reporting it as off.

Then check it against the page

A container says what should happen. Whether it does is read from the requests: the tag that is configured and the hit that actually left are two claims, and the gap between them is where most broken tracking lives. Debugging GTM without Preview mode covers that half, and for containers that send through their own domain, the server-side GTM guide covers where the hits go next.

Questions

Can I see a GTM container without being added to the account?

Yes, the published version. Google serves it as gtm.js to every browser that loads the site, so its tags, triggers and variables are readable from the container ID alone. Workspaces, drafts and version history stay inside the account.

Why are the tag names missing?

GTM does not publish them. Names, folders and notes exist only in the account; the file a visitor receives holds what the tags do, not what someone called them. Tag Master labels each tag by its type and the trigger that fires it instead.

Does this work for a server-side container?

No. A server container runs on its own host and its configuration is never sent to a browser. The web container that feeds it is readable, and its Google tag settings usually show the server address the hits are sent to.

Does reading a container send anything about me?

The request carries the container ID and nothing else, and the file is parsed as text — none of its code runs. It is the same file your browser already downloads when it opens the site.

The rest of this group: Containers and triggers

Try it on your own site

Tag Master is free, needs no account, and collects no data.

Add to Chrome — Free