What Is My Browser

Browser Checker for User Agent, Platform, and Screen Details

What is my browser displays the browser and environment details that are useful for support, testing, and troubleshooting. The visible result table can show browser name, browser version, user agent, platform, language, cookie status, screen size, browser viewport, and color depth. Some values come from the request and some visible screen fields are filled in by the page while it loads.

The tool is different from a domain checker because it does not ask you to enter a website address. It reports the environment you are currently using. That makes it useful when a website works for one person but fails for another, or when a developer needs enough information to reproduce a layout or compatibility problem.

How to Use the Page

1. Open the page in the browser you want to identify.
2. Wait for the browser details table to load.
3. Review the browser name and version first.
4. Copy or record the user agent only when a support request needs it.
5. Use screen, viewport, language, and cookie details to explain environment-specific behavior.

There is no required input field for a domain, file, or text value. The page is designed to show information about the active browser session. If you need to compare two devices, open the page on each device and compare the returned rows.

What the Browser Details Mean

Sharing Browser Details in a Useful Way

When reporting a problem, include only the details that help someone reproduce it. Browser name and version are usually the minimum. The user agent is useful when the issue may involve browser detection, bots, compatibility handling, or device classes. Platform and viewport size are useful for visual bugs. Language and cookie status are useful when the problem involves localization, preferences, sign-in behavior, or theme choices.

A concise report might include the browser version, platform, viewport size, page where the issue happened, and exact action that triggered it. That is much more useful than a screenshot without environment details.

Screen Size Versus Viewport Size

Screen size describes the device display. Browser viewport describes the area currently available to the web page. They are not always the same. On desktop, resizing the window changes the viewport but not the physical screen. On mobile, browser controls, zoom level, orientation, and responsive layout rules can change the space that the page actually uses.

• Use screen size to identify the device display range.
• Use browser viewport to reproduce responsive layout behavior.
• Use color depth only when visual rendering or display differences are relevant.
• Retest after rotating a mobile device or resizing a desktop window.

When Browser Detection Is Not Enough

Browser details explain the environment, but they do not prove the cause of every website problem. If a page fails only in one browser, these details help reproduction. If the same page fails everywhere, the site itself may need checking. That is when domain-based tools become more useful than browser identification.

For page delivery questions, use Check GZIP Compression. For HTTPS certificate questions, use the SSL Checker. For broken navigation or failed page links, run the affected URL through the Broken Link Checker.

Rechecking After Browser or Device Changes

Browser details can change after updates, privacy setting changes, extension changes, window resizing, device rotation, or switching between desktop and mobile modes. If a support issue appears only after one of those changes, run the check again and compare the new details with the previous report.

For repeatable testing, keep the same page, zoom level, orientation, and browser window size when possible. Consistent environment details make reports easier to verify. If the result is being sent to another person, include only the fields needed for troubleshooting and avoid adding unrelated personal context.

Using the Details in a Support Ticket

When a user reports that a page is broken, the browser details help turn the report into something reproducible. Include the browser name and version, platform, viewport size, cookie status when relevant, and the page where the issue happened. If the problem involves redirects, browser detection, mobile layout, or a compatibility rule, include the user agent as well. This gives the person investigating the issue enough context to test a similar environment.

Do not send every field when it is not needed. For a simple spelling mistake, browser details are irrelevant. For a layout problem that appears only on one device, viewport and platform matter. For a preference or login issue, cookies and language may matter. Matching the details to the problem keeps the report clear and avoids unnecessary noise.

If the issue disappears after an update or window resize, run the checker again. A before-and-after comparison can reveal whether the change was caused by a browser update, a responsive breakpoint, or a setting change.

Comparing Reports from Two Users

When two users see different behavior on the same website, compare their browser reports side by side. Look first at browser family, version, platform, viewport, language, and cookie status. These fields often explain differences in layout, localization, saved preferences, consent behavior, or compatibility. If one user has an older browser or a much smaller viewport, the issue may be reproducible without guessing.

The comparison is also useful for QA teams. Testers can attach the browser details to a bug report so developers know whether the issue appeared on mobile, desktop, a specific language setting, or a specific browser version. That context shortens the investigation.