{{ supportBriefText }}
| Field | Value | Copy |
|---|---|---|
| {{ row.key }} | {{ row.value }} |
{{ compatibilityVerdict.detail }}
{{ privacyVerdict.detail }}
Browser behavior depends on more than a name and version string. A site also reacts to storage access, secure context, viewport size, graphics support, language settings, privacy flags, and connection hints. When a login loop appears in one profile but not another, or a chart fails on one device while working on the next, those surrounding signals often explain the difference.
A viewport that shrinks from 1440 x 900 to 390 x 844 can move a page into a different layout before any account or code change is involved. Save-Data, reduced-motion, touch input, and missing WebGL can all push a site toward a lighter or more restricted experience. Browser diagnostics matter when you need to decide whether the problem is tied to the site itself, the current browser context, or the way the page is being viewed.
The snapshot produced here combines identity clues such as browser family, operating system, and client hints with execution checks such as secure context, storage access, graphics support, and modern runtime APIs. It also measures disclosure signals such as Global Privacy Control, Do Not Track, cookie and storage persistence, and how many identifying fields are exposed together.
These readings describe the current session, not a permanent device profile. Resize the window, switch networks, open a private window, or change blocking settings, and several values can move immediately. That is useful for troubleshooting because it shows what the site can see right now, but it also means a good comparison requires stable test conditions.
A result with lower exposure does not mean anonymity, and a result that looks compatible does not prove a website is healthy. The practical value is narrower and more useful: you get a concrete list of browser-side conditions that can explain why a page behaves one way in this session and a different way in another.
Browser diagnostics combine two kinds of evidence. One is identity data, such as the raw user-agent string, the browser engine, the operating system, and any User-Agent Client Hints (UA-CH) that the browser exposes. The other is execution context, such as whether the page is in a secure context, whether storage writes work, whether WebGL can open a context, what the viewport looks like, and whether the browser reports network-saving preferences.
Those signals matter because modern sites make assumptions from them. Secure contexts unlock APIs that many apps expect. Storage access affects whether sign-in state, cached preferences, or offline data survives. Display size, device pixel ratio, hover support, and touch input can change responsive layouts. Graphics APIs matter for canvases, maps, charts, and other rich surfaces.
The privacy side is different. It is less about whether a site can function and more about how much detail a site could combine into a recognizable profile. Screen dimensions, language order, time zone, hardware hints, network hints, browser version detail, and optional renderer data each add specificity. Global Privacy Control (GPC) and Do Not Track (DNT) express user intent, but they do not cancel the rest of the exposed fields.
| Signal family | Examples surfaced here | Why it changes behavior |
|---|---|---|
| Browser identity | Browser name, version, engine, operating system, raw user-agent, UA brands, full version list, platform version, architecture, model | Support teams use these to match a bug to a browser family, and extra version detail can make a session more distinguishable. |
| Display and input context | Viewport, screen resolution, device pixel ratio, color scheme, reduced motion, reduced data, hover, pointer profile, touch support | Responsive breakpoints, animation choices, pointer behavior, and media density all depend on these signals. |
| Secure and runtime APIs | Secure context, fetch, AbortController, ResizeObserver, IntersectionObserver, module scripts, CSS Grid, WebAssembly, service workers, clipboard | Current sites often assume these APIs exist, especially for authenticated flows and richer interfaces. |
| Storage and persistence | Cookies, local storage, session storage, IndexedDB, quota estimate, persisted flag | These signals affect whether sessions, cached assets, and saved settings can survive reloads and return visits. |
| Graphics path | WebGL, WebGL 2, WebGPU presence, optional renderer and vendor hints | Charts, maps, canvases, and media-heavy pages often degrade or fail when graphics support is restricted. |
| Privacy and network hints | GPC, DNT, connection type, downlink estimate, Save-Data, languages, time zone | Sites can use these to adapt consent, payload size, and localization, and they also contribute to browser fingerprint uniqueness. |
The check does not collapse everything into one generic pass or fail. It evaluates separate result surfaces, then escalates the final compatibility and privacy messages when a more serious condition appears. That makes it easier to see whether a problem comes from core browser features, storage access, graphics support, or disclosure level.
| Result surface | Condition in this check | Meaning |
|---|---|---|
| Core web runtime | Ready at 6 to 7 of 7 checks, caution at 4 to 5, limited at 0 to 3 | Shows whether the browser exposes the main APIs that many current sites assume. |
| Storage and session state | Ready at 4 of 4 checks, caution at 2 to 3, limited at 0 to 1; workspace-focused checks are downgraded if secure context is off | Explains sign-in persistence, remembered preferences, and whether storage-backed flows can survive normally. |
| Secure-context features | Limited when secure context is off, caution when secure context is on but clipboard writes are unavailable | Separates ordinary browser support from APIs that depend on HTTPS or an equivalent secure origin. |
| Graphics path | Ready when WebGL opens, caution when it does not, limited for graphics-heavy checks when WebGL is absent; Save-Data can soften the verdict | Shows whether graphics-rich pages have the rendering path they usually need. |
| Layout and input profile | Caution when viewport width drops below 360 px | Flags a very narrow browser window that can trigger compact layouts and touch-first interaction paths. |
| Fingerprint surface | High exposure at 8 or more identifying signal groups, moderate at 5 to 7, lower at 0 to 4 | Measures how much identifying detail is exposed together in the current session. |
| User-Agent disclosure | High exposure when high-entropy UA hints are returned, lower when only coarse browser data is available | More exact version and platform detail makes the browser easier to distinguish. |
| Graphics disclosure | Lower when renderer hint stays off, moderate when requested but hidden, high when renderer detail is returned | GPU detail helps graphics troubleshooting, but it also adds more identifying information. |
| Output field | Format | What it answers |
|---|---|---|
| Current Browser Snapshot | Headline plus status badges | Gives a fast summary of browser identity, compatibility, privacy, secure context, storage, and graphics state. |
| Ready-to-share brief | Short paragraph | Turns the most relevant context into a support-ready summary. |
| Compatibility verdict | Three-band verdict | Shows whether current sites are likely to work normally, with caveats, or with meaningful browser-side gaps. |
| Privacy verdict | Three-band verdict | Shows whether the current session exposes a lower, balanced, or high level of identifying detail. |
| Support facts | Badge list | Highlights the most useful facts to copy into a ticket or bug report. |
| JSON | Structured object | Preserves the raw snapshot so two sessions can be compared field by field. |
| Signal | What to keep in mind | Effect on interpretation |
|---|---|---|
| User-agent and UA-CH | Browsers can reduce or withhold detail, especially higher-entropy hints. | Missing platform or version detail is not proof of spoofing or breakage. |
| Storage probes | Private browsing, blocked cookies, embedded contexts, or site policy can block writes. | Restricted storage often explains login loops and reset preferences without proving the application is down. |
| Storage persisted | This reports whether the site's storage bucket is marked persistent against normal eviction pressure. | Yes means stronger retention, not a permanent promise that data can never be cleared. |
| Connection hint | effectiveType, downlink, and Save-Data are hints, not speed tests. |
Use them to explain payload or fallback behavior, not to certify real bandwidth. |
| Device memory and hardware concurrency | Browsers may coarsen or cap these values to reduce fingerprint precision. | Treat them as broad hardware hints rather than inventory-grade specifications. |
| Secure context and clipboard | HTTP pages, iframe policy, and browser permissions can change access to clipboard and related APIs. | Repeat the check in the same origin and security state as the failing page before drawing conclusions. |
| Renderer hint | Renderer detail appears only when explicitly requested, and some browsers still hide it. | No renderer detail does not prove there is no GPU. It only means that the browser did not expose it here. |
Start with Support handoff, keep Probe storage access on, and leave Include renderer hint off. That first pass gives the broadest explanation set for everyday troubleshooting without adding extra GPU detail that most support tickets do not need.
Compatibility target to Sign-in or workspace apps and compare Storage and session state with Secure-context features.Media or graphics-heavy pages and read Graphics path, WebGL, Viewport, and Connection hint together.Privacy verdict, Fingerprint surface, and User-Agent disclosure as one group.JSON after reading the shorter support summary. The brief is faster to share, while the JSON is better for field-by-field comparison.A strong-looking Compatibility verdict is not a certificate that the website is innocent. Extensions, blocked third-party storage, account state, and server-side bugs can still break one page while the browser snapshot looks normal. The verdict becomes much more useful when it lines up with a concrete field such as Secure context, IndexedDB, or WebGL.
If Secure context reads No, slow down before trusting clipboard or storage conclusions. Many sites only expose their full behavior over HTTPS, so a matching browser profile on a non-secure page can make a healthy site look more limited than it really is. When the snapshot is stable, copy the Ready-to-share brief first and attach the JSON only if the next person needs the full field list.
Current Browser Snapshot and the status badges to appear.Check goal. Support handoff opens the support-focused view, Modern web app compatibility opens Compatibility Lane, and Privacy and exposure snapshot opens Privacy Surface.Probe storage access on for sign-in or saved-setting problems, and enable Include renderer hint only when graphics troubleshooting truly needs GPU detail.Secure context off, Storage restricted, or No WebGL, note that before copying anything because those are high-value clues.Compatibility Lane or Privacy Surface for the deeper readout. Focus on Compatibility verdict, Graphics path, Storage and session state, Privacy verdict, and Fingerprint surface.Copy brief is best for tickets, Copy CSV and Download CSV work well for tabular evidence, Export DOCX builds a local document, and JSON preserves the full snapshot.Start with Compatibility verdict and Privacy verdict. They compress the biggest signals, but they only make sense when you pair them with the field that caused the warning. A browser that looks ready can still fail on one site, and a high-exposure reading can still reflect an ordinary modern browser session.
Ready for current sites means the main runtime and context checks look healthy. It does not rule out broken extensions, account-specific issues, or server-side bugs.Compatibility gaps likely is most useful when one field explains it clearly, such as Storage and session state, Secure-context features, or Graphics path.High exposure means many identifying signals are visible together. It does not mean tracking already happened or that sharing the snapshot is unsafe if you trust the recipient.Storage ready, Storage mixed, and Storage restricted describe access in this exact context. A private window, embedded frame, or stricter blocking policy can change them without any site code change.Viewport, Connection hint, and WebGL are worth rechecking after a resize, profile switch, or network change because those fields can move during the same session.The highest-confidence follow-up is to compare two stable snapshots: one from the working session and one from the failing session. Differences in Secure context, storage access, graphics availability, or privacy disclosure usually explain more than a browser name alone.
A dashboard reloads back to the sign-in screen after every refresh. With Sign-in or workspace apps selected, Compatibility verdict returns Compatibility gaps likely, Storage and session state is Limited, and Secure-context features still shows a healthy result. The detailed rows reveal that Local storage, Session storage, and IndexedDB are all blocked.
That pattern points to a browser-context restriction rather than an immediate application outage. The useful next test is a normal profile or a less restrictive storage setting, then a second snapshot to see whether Storage and session state rises from Limited to a healthier result.
A media dashboard opens, but its charts and canvas-based widgets stay blank. On the graphics-focused view, Graphics path reads Limited, WebGL is Unavailable, and Viewport is 320 x 640 with a coarse pointer profile. The final Compatibility verdict again becomes Compatibility gaps likely, but this time the cause is the missing graphics path and very narrow layout.
The result does not mean every site will fail on the device. It means this session lacks the rendering path the page expects. Retesting in a browser that exposes WebGL or on a wider window is the right comparison.
A user wants to send troubleshooting evidence without adding more identifying detail than necessary. With the privacy-focused view open and renderer detail left off, Privacy verdict still reads High exposure, Tracking preference signals shows Active because GPC is on, and User-Agent disclosure reports that higher-entropy hints are available.
That is not a contradiction. GPC expresses a privacy preference, while version, locale, screen, hardware, and UA-CH data can still make a session distinctive. The safest shareable artifact in this case is the Ready-to-share brief, with renderer detail still disabled unless the issue clearly involves GPU rendering.
Browser comes from the parsed user-agent string, while Browser full version can use UA-CH data when the browser exposes it. Some browsers reveal only coarse version detail, while others provide a fuller version list.
That usually means the current context would not accept a small read-write probe. Private browsing, embedded contexts, blocked cookies, site policy, or stricter privacy settings can all cause this. Compare the blocked result with Secure context, Cookies enabled, and the same check in a normal profile.
Storage persisted reports whether the origin's storage bucket is marked as persistent against ordinary eviction pressure. A Yes result is stronger than ordinary best-effort storage, but it is still not a promise that data can never be cleared by the user or the browser.
GPC and DNT are preference signals. They tell a site something about the user's privacy request, but the snapshot may still expose screen size, language order, time zone, connection hints, UA-CH detail, and other identifying fields. The verdict measures exposed detail, not just preference flags.
No. It only means the browser exposes the main features and context signals that many sites expect. Extensions, server-side faults, account state, and blocked third-party resources can still break one page. Use the snapshot as evidence, not as a final verdict.
Browsers expose DNT inconsistently because the feature is deprecated and never became a reliable enforcement mechanism. 1 asks not to be tracked, 0 allows tracking, and an unspecified result means the browser did not expose a DNT preference here.
The collected snapshot is assembled in the browser, and the copy, CSV, JSON, and DOCX actions generate local outputs from that data. The page still needs its own site assets to load before the check can run, but the snapshot it collects is not posted to a server by this check.