Client Hints Generator.
Build, test & debug UA-CH.

UA-CH exposes browser and platform metadata through structured HTTP request headers and, in supporting browsers, navigator.userAgentData. Use it where your application needs that metadata; it does not directly measure browser capabilities. Start with module 01 to inspect the header shapes.

Do not assume a universal replacement. Support varies by browser, field and policy, and some clients send no UA-CH. Keep a functional fallback while migrating specific parsing rules, and check the dated compatibility matrix before changing production behavior.

The basic UA-CH fields describe brands, mobile preference and platform. More detailed values, such as model, architecture or full versions, are higher entropy and require an opt-in scenario for browser delivery. The client may withhold values even when a server asks for them.

There are named synthetic fixtures for Chrome, Edge, Opera, their listed Android variants, Samsung Internet and Android WebView. The matrix provides documented version information for these seven targets. Real delivery must be tested in the actual browser or embedded WebView; selecting a fixture does not launch that browser.

UA brand lists can include deliberately unfamiliar GREASE-style entries and need not have a fixed order. Avoid rejecting a client because one brand is unknown. Use a Structured Fields-aware parser and test unknown brands as part of your migration.

Use Sec-CH-UA-Full-Version-List when full browser versions are needed and supported. Sec-CH-UA-Full-Version remains available here as a deprecated test field. In module 05, explicitly select Full-Version-List to request reported full versions; they may still be withheld.

Return an Accept-CH response header listing the request-header names you need on the HTML document (navigation) response. For example, Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Bitness asks a supporting browser to consider sending those fields on subsequent eligible requests. Chromium does not store Accept-CH received on fetch() or other subresource responses. Generate an opt-in snippet in modules 02–03, then check actual delivery in module 05.

Check that the actual response requests it through Accept-CH, that the browser supports it and that the context and applicable policies allow delivery. Then compare later requests, not just the initial navigation. An empty quoted model can also be a valid result, especially for desktop scenarios; absence alone is not proof of a server failure.

Select the needed fields, enter Vary/Critical-CH names in module 03, then choose the Nginx or Apache output in module 02. Review the generated snippet for your server scope, modules and existing headers. Test the configuration before deployment; this site does not apply changes to your infrastructure.

Accept-CH requests hints. Critical-CH identifies hints essential before rendering, which can affect retry behavior in supporting browsers. Vary tells caches which request fields distinguish representations. Our generator also includes selected critical fields in Accept-CH and Vary, but you must check how your server and CDN combine existing headers.

Choose the UA-CH Permissions-Policy output and enter an HTTPS origin in module 03. Review the receiving origin’s opt-in, browser support and any iframe allow configuration relevant to your use case. Delegation is separate from CORS; it does not authorize arbitrary cross-origin JavaScript access.

A WebView is embedded by an Android application, whose configuration and installed WebView version can affect user-agent metadata. A Chrome Android test does not certify that app’s WebView. Run the lab inside the target app where possible and record the actual WebView/app environment with your exported evidence.

Browser JavaScript cannot freely set reserved Sec-* request headers. Use the generated cURL command for a controlled custom-header request, and the negotiation lab for values the actual browser supplies. These are different experiments and should not be presented as interchangeable evidence.

Set profile A in module 01, enter your URL in module 02, and choose a contrasting profile B in module 04. Build the script and run it in a POSIX shell. Inspect status, headers and bodies, then repeat with stable application/cache conditions before concluding that UA-CH caused a difference.

No. It sends selected headers with cURL and records HTTP evidence. It does not reproduce browser negotiation, JavaScript execution, UA string consistency or TLS fingerprints. The script can reveal response differences, but dynamic pages and cache state can also produce them.

Open module 05 in the actual browser/version, select Full-Version-List if needed and run the experiment. Module 06 exports user-declared labels separately from browser-reported metadata and observed headers. If exact versions were not disclosed, preserve that uncertainty rather than treating a typed label as verified.

The browser stored an opt-in for this origin from an earlier navigation response with Accept-CH, for example a previous run. Select Clear origin opt-in in module 05; it navigates to a response with an empty Accept-CH header. Then run the experiment again. A clean browser profile or another local server port also gives a fresh origin. Record the conditions with your evidence.

The current cURL examples and A/B script target a POSIX shell. On Windows, use WSL or Git Bash and follow the README. Shell quoting and paths differ from native PowerShell, so do not assume the generated script is a PowerShell recipe.

Only use request fields in the cache key when they actually distinguish the representation, or configure an equivalent cache strategy at the edge. Unnecessary high-cardinality fields can fragment caches. Test both requests with and without hints; Accept-CH by itself does not mean that your response varies by every requested field.

No. Custom HTTP clients can forge hint values, and browser-reported metadata is not authentication. Do not use a generated profile as evidence of identity or as the only basis for access control. The response inspector is not a penetration test or security certification.

Generating fixtures, reading this browser’s values and inspecting pasted responses happen in this page. Running module 05 sends the browser-provided hints to this origin’s endpoints, which do not persist them. Completed reports stay in this tab’s sessionStorage until you clear them or close the tab. The hosting provider and Google’s advertising services process connection data independently; see the privacy notice.

Content-DPR is a deprecated image response header, not a request hint to insert into Accept-CH. The inspector identifies it for legacy troubleshooting. For new image-delivery work, review the current responsive-image specifications and browser behavior rather than copying a legacy header pattern.

No automatic search or performance improvement follows from adding headers. They can support a specific server adaptation, but measure its effect on content, latency and caching. Keep useful equivalent content when hints are absent, avoid using hints alone to classify crawlers and validate the deployed page in Search Console and performance tools.

Check the exact header, browser and version in module 08, including notes and aliases. Treat the source snapshot as documentation, then gather observed results in modules 05–06 under your real policy and origin conditions. A successful UA-CH test does not certify image hints or every other Client Hints family.