Track PDF Downloads in GA4: 5 Easy Setup Steps

Hi there! If you've been dreading another GTM setup just to see who's downloading your latest whitepaper, this one has some good news baked in.

Unlike a lot of the tracking gaps in GA4, this is a case where the platform already does more than most people realize, right up until it quietly doesn't. If you're trying to track PDF downloads in GA4 accurately, knowing exactly where that line sits is what separates a report you can trust from one with silent holes in it.

Here's the pleasant surprise: to track PDF downloads in GA4, you often don't need Google Tag Manager at all. Enhanced Measurement, on by default in every GA4 property, already watches for clicks on file links and reports them automatically.

Google's own Enhanced Measurement reference confirms the event it sends is called file_download, and the documentation lists the exact file extension pattern it matches against, PDF included alongside spreadsheets, presentations, archives, and several audio and video formats.

So before reaching for GTM to track PDF downloads in GA4, it's worth confirming this is already working for you. Click a real PDF link on your own site with Preview mode running, and there's a good chance the event is already there, no configuration required.

Understanding these parameters is the real foundation for anyone who wants to track PDF downloads in GA4 with any precision, since every report and exploration you build later pulls from exactly these four fields. When Enhanced Measurement catches a real click, it sends four parameters along with the event: file_extension, file_name, link_url, and link_text. Analytics Mania's own guide to GA4 file download tracking walks through each one and how they show up in reports.

Here's what a real click actually produces, captured straight from a genuine browser test rather than the documentation alone.

Two real clicks, one lowercase link and one uppercase, both correctly detected as PDF downloads.

Notice the second result: the link pointed to Annual-Report.PDF, uppercase extension and all, and file_extension still came back as a clean lowercase pdf. The real detection logic normalizes case before matching, which matters more than it sounds like, since plenty of real content management systems output file links in whatever case an editor originally uploaded them in.

// what a real file_download push looks like, captured from
// a genuine click in Chromium
{
  event: 'file_download',
  file_extension: 'pdf',
  file_name: 'annual-report.pdf',
  link_url: 'https://brandella.in/files/annual-report.pdf',
  link_text: 'Download the Annual Report (PDF)'
}

The automatic version has three real limits, and each one is a genuine reason to bring in GTM rather than a theoretical edge case for anyone who needs to track PDF downloads in GA4 with real accuracy across an entire content library, not just a handful of short, tidy links.

Analytics Mania's own testing found that link_url gets cut off at 100 characters, which matters more than it sounds like for a document buried a few folders deep. A real test against a 120 character file URL confirms exactly where that line falls.

A real long URL, truncated exactly where Google's own documentation says it will be, next to a real click that Enhanced Measurement never sees at all.

Second, the extension list itself is fixed. If your site serves a custom format, a .epub ebook or a proprietary export type that isn't on Google's default list, Enhanced Measurement simply never fires for it, and there's no setting inside GA4 itself to extend that list.

Third, and this is the one the real test above proves directly: detection is click based, watching for a real click landing on a real link. A "download" triggered by JavaScript, a button that calls window.open() with no actual <a> element behind it, produces zero automatic events, even though the JavaScript itself runs correctly and the file genuinely opens for the visitor.

For a file type outside Google's default list, Analytics Mania's own PDF tracking walkthrough with GTM and Analytify's own comprehensive GTM setup guide both use a Click trigger checking whether Click URL matches a RegEx, set to match case insensitively so an uppercase extension doesn't slip through. This is the exact same pattern worth reaching for any time you need to track PDF downloads in GA4 for a format Google's own list simply doesn't include.

Click URL   matches RegEx (ignore case)   \.epub([?#].*)?$

That single condition catches a real click on any link ending in .epub, uppercase or lowercase, with or without a query string trailing after it. Wire it to a GA4 event tag with a name like file_download or a custom name of your choosing, and the extension your default measurement misses now has its own coverage.

The case triggered entirely by JavaScript from earlier needs a different approach, since there's no <a href> for a Click URL condition to check in the first place. Our guide to tracking button clicks in GA4 covers the same All Elements versus Just Links distinction in more depth, and it applies here too: an All Elements trigger, scoped to the specific button's ID or class, is what actually catches this pattern.

From there, a Custom JavaScript variable can read whatever URL your own code is about to open, the same value your window.open() call already has, and pass it forward to the GA4 event tag as a real parameter, filling the exact gap the automatic detection can't reach.

Once the trigger fires, whichever variant you needed, the GA4 Event tag setup is the same regardless. Name the event clearly, file_download matches Google's own convention if you want your custom events to merge cleanly with the automatic ones in reports, and map each variable to an event parameter.

Google's own GA4 events reference documents the standard parameter names, and reusing them instead of inventing your own keeps custom and automatic file download events comparable inside the same GA4 exploration report. Google's own tag best practices guide makes a similar point about consistency: the easier a custom event is to compare against a built in one, the less duplicate reporting logic you end up maintaining later.

Testing this in Preview mode before publishing is the single habit that catches most mistakes early, whether you're adding your first custom trigger or you've already shipped several ways to track PDF downloads in GA4 across different parts of a large site.

Beyond the counting and case matching issues covered already, a few more patterns are worth watching for once your setup is live.

A PDF opened inside an embedded viewer, rather than downloaded directly, may never trigger a real navigation or file request the way a normal link does, depending on how the viewer itself is built. MDN's own reference for Element.closest(), the same method real click listeners use to find the nearest matching link, is worth understanding if you're debugging why a click inside a custom viewer isn't being caught.

And if your PDFs live behind a login or a gated form, remember that a download event only tells you a click happened to track PDF downloads in GA4 as a click signal, not that the file finished downloading or that the visitor found what they needed inside it. For the broader mistakes that break tracking setups like this one, our guide to common GTM mistakes that break your tracking is worth reading alongside this one, and if you haven't already, our guide to the GTM data layer explains exactly where these pushes actually go once GTM receives them.