The Application Insights JavaScript snippet explained

The snippet is the most copied and least read piece of Application Insights. It’s minified into one long line, so most people paste it, change the connection string and move on. That works, until a content security policy blocks it, a consent banner requires cookies to wait, or page views don’t line up with server requests.

What the loader script does

Microsoft’s current loader is an inline function followed by a configuration object. The configuration is the readable part:

<script type="text/javascript">
!(function (cfg){ /* minified loader, copied unchanged from Microsoft's documentation */ })({
  src: "https://js.monitor.azure.com/scripts/b/ai.3.gbl.min.js",
  crossOrigin: "anonymous",
  cfg: {
    connectionString: "InstrumentationKey=...;IngestionEndpoint=https://..."
  }
});
</script>

The minified function does five things, in order:

1. Creates the global instance, window.appInsights by default (change it with name if two SDKs share a page).
2. Adds proxy methods such as trackEvent, trackPageView, trackException and setAuthenticatedUserContext. Calls made before the SDK arrives go into a queue and run once it loads, so your page code never has to wait.
3. Hooks window.onerror to catch errors that happen while the SDK is still loading, unless exception tracking is disabled.
4. Adds a script tag for src after a delay set by ld (0 ms by default; a negative value blocks the page load and puts the tag in <head>). With sri: true it fetches an integrity file and checks the script; crossOrigin adds that attribute to the tag.
5. Handles failure. If the script can’t be loaded from the public CDN, the cr option retries from Microsoft’s backup CDN hosts, and the loader then sends an SDKLoadFailed exception straight to the ingestion endpoint in your connection string, so a blocked SDK still shows up in your data. dle: true suppresses that report.

Once loaded, the SDK tracks the page view (Microsoft collects page views by default) and calls onInit with the SDK instance, the right place to add browser telemetry initializers.

Content Security Policy

The loader is an inline script that adds another script from a CDN, so a strict Content Security Policy has to allow both: the inline block (with a nonce or hash) and the CDN host in script-src. The SDK then sends telemetry to the ingestion endpoint from your connection string, which connect-src must allow. On ASP.NET Core, the server SDK’s ScriptBody (below) exists precisely so you can write the <script> tag with your own nonce. The snippet package also documents Trusted Types support from version 1.2.2, for sites that require require-trusted-types-for 'script'.

Loader script or npm package

The npm form, for comparison:

import { ApplicationInsights } from "@microsoft/applicationinsights-web";

const appInsights = new ApplicationInsights({
  config: {
    connectionString: "InstrumentationKey=...;IngestionEndpoint=https://...",
    enableCorsCorrelation: true,
    disableCookiesUsage: true,
  },
});
appInsights.loadAppInsights();
appInsights.trackPageView();

If you generate pages server-side and want the loader without pasting minified code into a template, the @microsoft/applicationinsights-web-snippet package returns the script for a configuration (getSdkLoaderScript(config)), including the integrity-checked variant.

Classic SDK 2.x

The server SDK has long been able to write the snippet for you. In ASP.NET Core 2.x, inject JavaScriptSnippet in _ViewImports.cshtml and render it at the end of <head>:

@inject Microsoft.ApplicationInsights.AspNetCore.JavaScriptSnippet JavaScriptSnippet
...
    @Html.Raw(JavaScriptSnippet.FullScript)
</head>

ScriptBody (from SDK 2.14) gives you just the script body, so you can write your own <script> tag with a CSP nonce. With EnableAuthenticationTrackingJavaScript, the injected script also passes the signed-in user’s name to setAuthenticatedUserContext. The injected version uses default settings only; for any other configuration, Microsoft says to remove the injection and add the SDK yourself.

Today: SDK 3.x and the Microsoft OpenTelemetry Distro

SDK 3.x keeps JavaScriptSnippet for ASP.NET Core (its IHttpContextAccessor constructor parameter became optional) and keeps EnableAuthenticationTrackingJavaScript. The Microsoft OpenTelemetry Distro has no snippet helper: server-side OpenTelemetry doesn’t replace browser telemetry, so add the loader script to your layout yourself, or render it with the snippet package.

Page views and server requests in one trace

The JavaScript SDK records Ajax and fetch calls as dependencies of the page view and sends correlation headers with them: W3C traceparent and tracestate, plus the older Request-Id while distributedTracingMode is left at its default AI_AND_W3C. Your server SDK or distro reads them, so the server request becomes a child of the browser call, and the end-to-end transaction view shows both.

Headers are only added to calls to the page’s own domain. For an API on another host, including a subdomain, set enableCorsCorrelation: true, make sure the API’s CORS policy allows the headers, and exclude third parties that reject unknown headers with correlationHeaderExcludedDomains (Microsoft’s example excludes *.auth0.com). See request naming for how those server requests are grouped.

Switching it off, and consent

• One page: don’t include the loader on it, or set disableTelemetry: true in that page’s cfg; the SDK then neither collects nor sends.
• Cookies before consent: set disableCookiesUsage: true, then appInsights.getCookieMgr().setEnabled(true) after the user agrees. Without cookies, user and session IDs can’t persist across page loads, which affects user counts; see users and sessions.
• Volume: samplingPercentage (default 100) keeps a share of browser telemetry; choose a value of 100/N, and match the server’s rate if you use fixed-rate sampling there too. The sampling guide explains why.

Telemetry initializers enrich or drop items: add one in onInit (or with addTelemetryInitializer in the npm form) and return false to drop an item. That’s also where you’d attach browser context such as the connection type the browser reports, as a custom property.

The connection string in the browser

Anything in the page is public, and Microsoft is explicit that the connection string isn’t a security token. Two consequences follow. Anyone can send telemetry to that resource, and browser telemetry can’t simply use Microsoft Entra authentication. Microsoft’s suggestions are a separate Application Insights resource with local authentication for browser telemetry, or a relay (for example Azure API Management) that authenticates with a managed identity, with the connection string’s IngestionEndpoint pointing at it. The telemetry channels guide covers that override.

Troubleshooting