posthog-js

About

Posthog-js allows you to automatically capture usage and send events to PostHog.

What detecting posthog-js tells you about a site

posthog-js marks a product that instruments user behaviour, and usually one that leans toward the all-in-one, often self-hostable PostHog platform: product analytics, feature flags, session replay and experiments in a single SDK. Finding it tells you the team tracks events and funnels, and quite possibly runs feature flags and A/B tests from the same source. Its presence skews toward product-led and engineering-driven companies, since PostHog is popular with teams that want their analytics in-house or open-source rather than handing data to a pure third-party. It is a clear sign that product decisions here are measured, not guessed.

Why the exact posthog-js version matters

posthog-js evolves quickly, and capabilities like autocapture defaults, session replay, surveys and the feature-flag bootstrap have arrived and changed across versions. The exact version tells you which of these subsystems are even available and how aggressively the SDK captures by default, which has real privacy and data-volume implications worth knowing.

posthog-js in a real-world stack

When you find posthog-js in a bundle, it rarely travels alone. Often the only analytics SDK present, since PostHog deliberately bundles flags, replay and experiments together.

Quick facts

What posthog-js pulls in

posthog-js declares 10 direct dependencies — each one also rides into any bundle that ships posthog-js, so they are detection targets too. Reading them is a quick way to understand the package's real footprint .

How Sourcemap Explorer detects posthog-js

posthog-js ships as v1.413.3, published 2026-08-06 and carries 10 direct dependencies, 1,302 versions on the registry. Those exact numbers are the footprint Sourcemap Explorer matches when posthog-js rides inside a deployed bundle — here is how the detection works.

We catch posthog-js from two complementary signals: bundled source paths and the embedded package.json. Modern bundlers (webpack, Vite, esbuild, Rollup, Turbopack) preserve the original node_modules/posthog-js/ paths inside the JavaScript sourcemap's sources[] array — that's the canonical signal. When the matching package.json is also captured in sourcesContent[], we read the exact version field — patch number included. No regex guessing, no version inference.

1. 1

   Confirm the site exposes sourcemaps

   In DevTools Network, check the response headers of any application script for `SourceMap` or `X-SourceMap`. Failing that, fetch the script's last 4 KB and look for a `//# sourceMappingURL=` comment — that map is where the `posthog-js` paths live.

2. 2

   Find the package in the bundle

   Open DevTools → Network → reload. Click any application script and look at its sourcemap. Inside, search `sources[]` for entries matching `node_modules/posthog-js/` — every match confirms the package is bundled. The matching `sourcesContent[i]` for `node_modules/posthog-js/package.json` gives you the exact installed version.

3. 3

   Read the version directly from package.json

   Run `jq -r '. as $m | $m.sources | to_entries[] | select(.value | endswith("node_modules/posthog-js/package.json")) | $m.sourcesContent[.key] | fromjson | .version' bundle.js.map`. Sourcemap Explorer automates the same query in the popup.

Recent security advisories for posthog-js

The 2 most recent advisories affecting some versions of posthog-js, aggregated from OSV.dev (GitHub Advisory + CVE data). A listing here doesn't mean the version a given site ships is affected — each advisory applies to a specific version range. Sourcemap Explorer reads the exact bundled version so you can check it against these ranges.

1. MAL-2025-191402· 2025-11-25

   Malicious code in posthog-js (npm)

2. MODERATECVE-2023-32325· 2023-05-22

   Potential for cross-site scripting in PostHog-js

Recent versions

posthog-js README

Live mirror of the GitHub README, for reference. Updated whenever the repo's default branch changes.

FAQ