Home
DocumentationDebugging tools

PostHog debugging tools: Network, Toolbar, and PostHog Debugger

Which PostHog debugging tool should you use?

Use browser Network tools when the question is about the HTTP request itself. Use the official PostHog Toolbar when you have project access and want PostHog's on-page actions, heatmaps, feature-flag overrides, or event debugger. Use PostHog Debugger when you want an unofficial, no-login DevTools view that decodes supported PostHog traffic and connects it with browser-visible SDK state.

The tools are complementary. Network tools provide the most complete transport evidence, the Toolbar provides authenticated PostHog workflows, and PostHog Debugger organizes local browser evidence around PostHog-specific questions.

Compare Network, Toolbar, and PostHog Debugger

Setup

  • Browser Network tools: Open the browser's built-in DevTools Network panel, reload the page, and reproduce the flow. No extension or PostHog-specific setup is required.
  • Official PostHog Toolbar: Launch it from a PostHog project for an authorized URL. PostHog's Toolbar documentation explains the launch flow and notes that the Toolbar is available for the JavaScript web SDK.
  • PostHog Debugger: Install from the Chrome Web Store or Firefox Add-ons, open the PostHog DevTools panel, and reload. Follow Getting started for a clean first capture.

Login requirements

  • Browser Network tools: No PostHog login. You only need access to the page and its browser DevTools.
  • Official PostHog Toolbar: A PostHog account with access to the project and permission to use the Toolbar is required. The site must also be authorized before the standard launch flow or bookmarklet can open it.
  • PostHog Debugger: No PostHog login. It observes the inspected page and browser traffic, so it cannot read private project settings or prove which private project owns a public token.

Payload decoding

  • Browser Network tools: Shows the request URL, headers, body, response, initiator, and timing. Raw JSON is easy to read, but batches, form-encoded bodies, base64, or compressed payloads may need manual decoding.
  • Official PostHog Toolbar: Its event debugger shows captured events and properties, supports filtering, and can copy or export event JSON. PostHog documents these controls in the Toolbar event-debugging guide.
  • PostHog Debugger: Decodes supported ordinary JSON, batches, form-encoded data, base64, and gzip into an event-focused view with properties, warnings, and raw payload evidence.

Configuration visibility

  • Browser Network tools: Shows configuration only when it affects a request. You can infer a token, host, payload, or response, but most SDK options require separate source, storage, or console inspection.
  • Official PostHog Toolbar: Focuses on official product workflows such as actions, heatmaps, feature flags, and event debugging. It is not a dedicated inventory of the page's SDK configuration.
  • PostHog Debugger: Config summarizes the compatible browser SDK state the page exposes, including version, project token, API host, capture options, consent or opt-out state, and configuration warnings.

Identity

  • Browser Network tools: Can reveal distinct_id, device IDs, and person updates when they are present in requests, but reconstructing an identity transition across requests is manual.
  • Official PostHog Toolbar: Event properties can show identity evidence, while authenticated PostHog views can help relate events to project data. The official JavaScript web SDK guide defines the supported identify and reset workflow.
  • PostHog Debugger: Identity shows the current browser-visible distinct ID, device ID, session ID, groups, and identified state. Its timeline records observed identify, alias, group, and reset activity.

Feature flags

  • Browser Network tools: Shows flag-evaluation requests and responses, but interpreting state and matching it to application behavior is manual.
  • Official PostHog Toolbar: Can search and override feature flags for the current browser without changing other users or backend evaluations. This is the best fit when testing an official project-managed flag workflow.
  • PostHog Debugger: Shows browser-visible flags, payloads, overrides, and relevant network responses for diagnosis. It reports observed state but does not edit the project or replace official flag testing.

Network diagnosis

  • Browser Network tools: The most complete choice for headers, redirects, initiators, request and response bodies, connection timing, CSP, CORS, and non-PostHog traffic.
  • Official PostHog Toolbar: Confirms which events the JavaScript SDK captured, but it is not designed as a request-delivery inspector.
  • PostHog Debugger: Filters for PostHog-shaped requests and relates decoded events to delivery evidence such as URL, status, size, timing, blocking, and non-2xx responses. Use the browser Network panel when you need full headers, initiators, or an unrecognized custom route.

Limitations

  • Browser Network tools: General-purpose and authoritative for browser requests, but not PostHog-aware. They do not summarize SDK configuration, follow identity calls, or interpret product-specific warnings for you.
  • Official PostHog Toolbar: Limited to the JavaScript web SDK, requires authenticated project access, and can be affected by authorization, CSP, blockers, reverse-proxy configuration, or application routing.
  • PostHog Debugger: Unofficial and limited to browser-observable activity after its hook is installed. It cannot inspect server-side SDK calls, PostHog ingestion internals, private project settings, proxy logs, or every custom endpoint and encoding. Review what PostHog Debugger can detect before treating absent panel data as proof that nothing happened.

Use browser Network tools for transport evidence

Choose the built-in Network panel when you need the complete HTTP record or when PostHog Debugger does not recognize a custom proxy path. It is the strongest source for request headers, response bodies, redirects, CORS, CSP, initiators, and timing across all page traffic.

A practical sequence is to filter by the configured PostHog host or common paths such as /i/v0/e/, /e/, /batch/, /capture/, /decide, /flags, or /s/; reproduce one known action; then inspect the request body and response. A successful 2xx response proves that the endpoint accepted the HTTP request, not that the event completed PostHog's ingestion and query pipeline.

Use the official PostHog Toolbar for project workflows

Choose the Toolbar when you can sign in to the intended project and need an official on-page workflow. It can create and review actions, visualize heatmaps, override client-side feature flags, and inspect the event stream on an authorized site. Because PostHog documents the Toolbar as a JavaScript web SDK feature, it is not the general choice for diagnosing server-side SDK traffic.

The Toolbar is also the better authority for behavior tied to the PostHog project. PostHog Debugger does not authenticate, so it deliberately cannot confirm project membership, change a flag, create an action, or inspect private project-side data.

Use PostHog Debugger for local, no-login diagnosis

PostHog Debugger is useful when a developer or QA tester needs a PostHog-specific view without access to the PostHog account. Its Events, Network, Config, Identity, and Flags & Session views keep the browser-side evidence together while a flow is reproduced.

Use it to answer questions such as:

  • Did the page initialize a compatible PostHog browser SDK with the expected token and host?
  • What event and properties did the page create?
  • Did an identity or consent transition change the observed state?
  • Which feature flags and session or replay details are visible to the page?
  • Did a recognized request leave the browser, and what status did it return?

The extension processes inspected debugging data locally and requires no PostHog login. Read the privacy policy for the exact distinction between inspected data and the extension's limited product-usage analytics.

Combine the tools when events are missing

  1. Open DevTools before reloading so both Network and PostHog Debugger can observe startup activity.
  2. Use PostHog Debugger Config to check SDK state, token, host, consent, and identity.
  3. Reproduce one known event and inspect its decoded payload in Events.
  4. Match it to Network in PostHog Debugger, then open the browser Network request when you need complete transport detail.
  5. If the browser sent a plausible request successfully, use the official Toolbar or authenticated PostHog project views to check project-side behavior.

Follow the answer-first PostHog events not showing checklist for browser-side and project-side diagnosis. For general capture problems and safe evidence sharing, keep troubleshooting and privacy nearby.

Install or continue reading

Install PostHog Debugger for Chrome and compatible Chromium browsers or Firefox. The extension is an independent, unofficial product and is not affiliated with, endorsed by, or sponsored by PostHog.

Continue with Getting started, then use the panel reference to learn the dedicated views.

For extension-specific help, use the support page or GitHub issue tracker. Review the complete changelog when a diagnostic surface or limitation differs from an older build.