How to Tell If a Website Uses FullStory

FullStory is a leading digital-experience analytics platform: it records complete session replays and surfaces frustration signals like rage clicks and dead clicks. If you want to know whether a site runs it, the fastest checks are to look for the edge.fullstory.com/s/fs.js script in the Network tab or to type FS into the browser console. This guide covers every reliable signal, the recording mechanics behind them, and what a FullStory install tells you about the team.

What is FullStory?

FullStory belongs to the session-replay and experience-analytics category, alongside tools like Hotjar, Microsoft Clarity, Contentsquare and LogRocket. Rather than counting page views, it reconstructs what individual visitors actually did — every mouse movement, scroll, click and form interaction — into a replayable video, then layers analytics on top: conversion funnels, click maps, and automated detection of frustration signals such as rage clicks (rapid repeated clicking) and dead clicks (clicks that do nothing).

Because it is a premium, deliberately implemented tool, FullStory's presence signals a team that takes qualitative UX and conversion-rate optimisation seriously — usually a product, design or growth function with budget. It is common on SaaS apps, ecommerce checkouts and high-value lead-generation flows, exactly the places where understanding individual user behaviour pays off.

How FullStory loads and sends data

A FullStory install drops a snippet that sets a couple of window properties — window['_fs_org'] (the organisation ID) and window['_fs_namespace'] (usually 'FS') — and then asynchronously loads the recorder, fs.js, from edge.fullstory.com/s/fs.js (older installs used fullstory.com/s/fs.js). Once running, the recorder serialises the DOM and the stream of user interactions and sends them to FullStory's ingestion endpoint, rs.fullstory.com (and related *.fullstory.com hosts), continuously throughout the session.

Identity and session continuity are stored in a fs_uid cookie that encodes the org ID and the user/session identifiers. Because the recorder captures the live DOM, you will also see ongoing background requests during the session rather than a single beacon — a useful tell that distinguishes replay tools from simple page-view trackers.

How to tell if a website uses FullStory

Confirm at least two of the following.

1. View the page source. Search the HTML for fullstory, _fs_org, _fs_namespace or fs.js. The install snippet sets window['_fs_org'] = 'ABCDE' and loads the recorder script.

2. Check the Network tab. Filter for fullstory. You will see the edge.fullstory.com/s/fs.js download and a stream of session-data requests to rs.fullstory.com. The continuous nature of these requests is characteristic of a replay tool.

3. Use the console. Type FS and press Enter. A live install returns the FullStory object exposing FS.identify, FS.event, FS.setUserVars and FS.getCurrentSessionURL. Running FS.getCurrentSessionURL() returns a direct link to the current recording — definitive proof.

4. Inspect cookies. Look for the fs_uid cookie (and sometimes fs_lua). The fs_uid value embeds the organisation identifier.

5. Check window properties. In the console, evaluate window['_fs_org'] and window['_fs_namespace']; populated values confirm the install and reveal the account.

What the FullStory signals look like

GET  https://edge.fullstory.com/s/fs.js
POST https://rs.fullstory.com/rec/...      (streamed session data)
window['_fs_org'] = "o-1ABCDE-na1"
Cookie: fs_uid = "...org+session identity..."

The combination of the fs.js loader, the FS global with a working getCurrentSessionURL(), and the fs_uid cookie is conclusive.

FullStory versus similar tools — avoiding false positives

The session-replay category is crowded, so match the exact fingerprint. FullStory uses edge.fullstory.com/fullstory.com, the FS global and _fs_org; Hotjar uses static.hotjar.com and the hj/_hjSettings globals; Microsoft Clarity uses clarity.ms and the clarity global; LogRocket uses cdn.logrocket.io and the LogRocket/_lr_ namespace; Contentsquare uses t.contentsquare.net and _uxa. They all record sessions, but no two share a fingerprint. FullStory can also be loaded through a tag manager or a CDP, so the script may appear only after those execute — always check the live page. Finally, because replay tools stream continuously, do not mistake their ongoing requests for a performance problem; that traffic is the recording.

How reliable is each FullStory signal?

A working FS.getCurrentSessionURL() is definitive — it proves the recorder is live and producing a session. The streamed rs.fullstory.com requests and the fs_uid cookie are close behind. The _fs_org window property is strong and bonus-rich because it names the account. A static fs.js reference is the weakest standalone signal, since a snippet can be present but disabled by consent gating. Treat the session URL, the cookie, or active rs.fullstory.com traffic as conclusive; treat the bare script as a lead.

What a FullStory install reveals about a company

FullStory is a premium tool, so finding it tells you the organisation has budget and a function — product, design, UX research or CRO — that cares about how individuals experience the site, not just aggregate traffic. The places it is deployed are informative: on a checkout or signup flow it signals active conversion optimisation; on a logged-in app it signals product-experience research. Because FullStory also offers frustration analytics and funnels, its presence often means the team is hunting for friction systematically rather than guessing. If you sell UX research, CRO, accessibility or analytics services, that is an ideal-fit buyer who already values qualitative insight.

FullStory in a modern measurement stack

FullStory typically complements rather than replaces other tools. A mature stack might run Google Analytics 4 for acquisition, a product-analytics tool like Amplitude or Mixpanel for behavioural metrics, and FullStory for the qualitative "watch the replay" layer — so finding FullStory should prompt you to look for those companions. Replay tools also raise privacy considerations (they can capture form input unless masked), so a careful FullStory deployment usually coincides with a consent-management platform and explicit field masking, which is itself a maturity signal. For an auditor, record the org ID, whether consent gating is present, and which analytics tools coexist — together they describe how seriously the company invests in understanding its users.

A quick FullStory detection checklist

• Filter the Network tab for fullstory; the edge.fullstory.com/s/fs.js load and rs.fullstory.com stream are conclusive.
• Search the source for _fs_org, _fs_namespace and fs.js.
• Type FS in the console and run FS.getCurrentSessionURL().
• Check cookies for fs_uid (and fs_lua).
• Evaluate window['_fs_org'] to read the account identifier.
• Don't treat a bare fs.js script as proof if it may be consent-gated.

Privacy, masking and consent with FullStory

Because session replay can capture whatever appears on screen, privacy handling is central to any responsible FullStory deployment — and it is also a rich source of intelligence when you audit a site. By default FullStory masks input in many fields, but teams configure exactly what is recorded using the fs-exclude, fs-mask and fs-unmask CSS classes and the data-fs-* attributes, which block, mask or explicitly allow specific elements. If you inspect the DOM and see those classes around forms, payment fields or personal data, you are looking at a team that has thought carefully about what it captures — a genuine maturity signal. Conversely, a replay recorder firing on a checkout with no masking attributes anywhere is a privacy red flag worth noting, and a clear opening if you sell compliance or privacy-engineering services.

Consent gating matters just as much. In well-run deployments in the EU and UK, fs.js only loads after the visitor accepts analytics cookies through a consent-management platform, so you may need to accept cookies before the recorder appears at all. If you observe FullStory loading and streaming regardless of the visitor's consent choice in a strict jurisdiction, that is a finding in its own right — both a compliance risk for the site owner and a useful data point for anyone assessing how seriously the organisation takes data protection. Checking the order in which the consent banner, the CMP script and fs.js load tells you whether the deployment is compliant by design or merely bolted on.

A two-minute FullStory confirmation walkthrough

Open the site in a fresh browser tab with developer tools open on the Network panel, and accept cookies if a banner appears. Type fullstory into the request filter and reload: you are looking for edge.fullstory.com/s/fs.js. Switch to the Console and type FS — you should get the FullStory object back. Run FS.getCurrentSessionURL(); a returned URL is your conclusive proof, and it even links straight to the live recording of your own visit. Finally, open the Application panel, expand Cookies, and confirm the presence of fs_uid. With three independent signals gathered in under two minutes, you have not only confirmed FullStory but also learned the organisation ID (from _fs_org) and whether consent gating is in play — a far richer result than a simple yes/no, and exactly the kind of context that makes a sales or research conversation land.

Detecting FullStory at scale

Checking one page is a quick console call. To find every site in a list that runs session replay — for CRO prospecting or competitive research — automate it. StackOptic detects FullStory and thousands of other technologies from a real browser, catching tag-manager and CDP-injected installs. See how to find out what analytics a website uses and the FullStory profile for more.