اطلاعات مرورگر و صفحه

Every browser and screen detail, read locally in seconds

This browser and screen info tool is a one-stop dashboard for everything your browser knows about your device. In a single glance you get your browser name and version, operating system, screen resolution, live viewport size, device pixel ratio, aspect ratio, device type (mobile, tablet, or desktop), GPU renderer, time zone, language, and network connection type — all grouped into clearly labeled sections instead of a dense table.

Every value is read in your browser using standard JavaScript and Web APIs and displayed locally — nothing is uploaded, nothing is logged. Click any row to copy the value, copy a full summary with one button, or download everything as a structured JSON file. The page works offline after load and updates certain values (viewport, orientation, breakpoint) live as you interact with the browser window.

Screen resolution vs. viewport: the difference that trips everyone up

The most common confusion is why the browser reports a smaller size than the monitor you bought. Screen resolution is the full physical pixel size of your display — what Windows Display Settings, macOS System Information, or your monitor manufacturer lists. The viewport is the visible area of the web page inside the browser window, and it's almost always smaller.

The viewport is narrower because it excludes the browser's chrome (tabs, address bar, bookmarks bar, scrollbar) and the OS taskbar. On high-density 'Retina' screens it's also reported in CSS logical pixels, not physical pixels — so a 2560px-wide display with DPR 2 shows a viewport of ~1280 CSS pixels. Because the viewport is what CSS media queries and responsive layouts respond to, this tool updates it live as you resize the window or rotate your device, and shows the active Tailwind breakpoint alongside it.

Device pixel ratio, aspect ratio, and refresh rate

Device pixel ratio (DPR) tells you how many physical pixels your screen uses to render each CSS logical pixel. Standard monitors are 1×; most modern smartphones and Retina laptops are 2× or 3×, which is why text and icons look sharper on them. DPR also changes when you zoom the browser — this tool updates the displayed value live as you zoom in or out.

The tool computes the aspect ratio of your screen and your current viewport separately, snapping each to the nearest named ratio (16:9, 16:10, 3:2, 4:3, 21:9). It reads your color depth (typically 24-bit), detects your display's color gamut (sRGB, Display P3, or Rec. 2020), and estimates refresh rate in Hz by sampling animation frames — useful for confirming whether a high-refresh-rate display is running at its full rate or has been throttled by power-saving settings.

Browser fingerprinting: what any website can see about you

Everything this tool displays is exactly what any website you visit can silently read from your browser — no special permissions, no prompts. Screen resolution, viewport, device pixel ratio, time zone, language, GPU model, fonts, touch capability, battery level, and dozens more attributes combine to form a browser fingerprint. Research from the Electronic Frontier Foundation found that a complete fingerprint uniquely identifies more than 80% of web users — and it works identically in incognito or private mode, since those modes only block cookies, not API access.

Seeing your fingerprint attributes here is a useful privacy audit. Unlike competitor tools such as BrowserLeaks, WhatIsMyBrowser.com, and Panopticlick (Cover Your Tracks) that make server requests to check your IP, this tool never contacts a server. You see exactly what you expose — and nothing you enter or view here is collected, stored, or shared.

Built for developers: breakpoints, dark mode, GPU, and accessibility signals

For front-end and QA work, this tool surfaces signals you'd otherwise dig for in DevTools. The active CSS breakpoint updates live as you resize — you can see exactly when a Tailwind sm/md/lg/xl/2xl breakpoint fires. prefers-color-scheme (dark or light), prefers-reduced-motion, and prefers-contrast are shown as the values your CSS receives — useful for testing accessibility-aware stylesheets. The color gamut reading confirms whether a Wide Color display is correctly identified by the browser, essential when designing for iPhone Pro or iMac screens that support Display P3.

The GPU / WebGL renderer shows the actual graphics hardware string reported by the browser — handy for reproducing GPU-specific rendering bugs or confirming hardware acceleration is active. Pointer type (mouse, touch, or pen) shows which CSS pointer: media query evaluates to true. All of these values are copyable individually or exportable as JSON, making it easy to include device context in bug reports.

How this compares to WhatIsMyBrowser.com, BrowserLeaks, and Panopticlick

WhatIsMyBrowser.com makes a server call to detect your public IP, ISP, and geolocation — data that UtiloKit deliberately does not collect, since returning it requires your request to leave your device. WhatIsMyBrowser also upsells API access and browser management features behind a paywall. BrowserLeaks.com is aimed at security researchers and lists 30+ individual tests in separate pages, making it thorough but slow to scan and not designed for copy-pasting into tickets. EFF's Panopticlick (now Cover Your Tracks) focuses specifically on fingerprint uniqueness and ad-tracker blocking, not on providing copyable developer data.

UtiloKit prioritizes a different use case: a clean, fast, grouped dashboard of browser and screen info that you can read in seconds, copy with one click, and export as JSON — with the guarantee that nothing ever leaves your browser. No server calls, no account, no IP logging, no paywalls.

Works on iPhone, Android, tablet, and every desktop browser

The tool is fully responsive and works identically on iOS Safari, Android Chrome, Samsung Internet, Firefox for Android, and every major desktop browser. On a phone you get the real viewport dimensions, device pixel ratio (3× on iPhone 15 Pro, for example), battery level where permitted, touch capability, and portrait/landscape orientation — all updating live as you rotate the device.

Unlike relying on your phone's Settings app (which shows marketing resolution, not CSS pixels) or asking a developer to hard-code device dimensions, this tool shows precisely what the browser reports to websites for your specific device with your specific browser and zoom level. Bookmark it and reach for it any time you need an accurate snapshot of how your device appears to the web.

The strange history of the User-Agent string

The User-Agent string was introduced by the NCSA Mosaic browser in 1993 as a simple identifier sent with every HTTP request. Netscape Navigator, which dominated the mid-1990s web, established the format Mozilla/version — the 'Mozilla' name was Netscape's internal codename. Web servers quickly adopted server-side logic like 'if the browser is Mozilla, serve the full layout; otherwise serve plain HTML,' because only Netscape supported the richer features those layouts required. When Microsoft launched Internet Explorer in 1995, it faced an immediate problem: websites were locking it out because its UA string did not say Mozilla. Microsoft's solution was to ship IE with a string that read Mozilla/2.0 (compatible; MSIE 3.0; Windows 95) — announcing itself as a Mozilla-compatible browser. It was a lie of compatibility, not deception.

Every major browser that followed inherited this pattern of claiming to be all previous browsers to avoid being served degraded content. Today, Chrome's full UA string reads something like Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 — it simultaneously claims to be Mozilla, Apple's WebKit engine, the KHTML layout engine, Gecko (Firefox's engine), and Safari, while actually being Chrome running the Blink engine. None of those tokens is accurate; all of them are there to prevent legacy server-side sniffing code from sending Chrome a degraded response. The UA string became an archaeological record of browser compatibility wars rather than a truthful identifier.

Recognising that the UA string had become both unreliable and a significant browser fingerprinting vector, Google began the User-Agent Reduction initiative in 2021. By 2023, Chrome had frozen the minor version number, reduced OS detail to a small set of known strings, and unified the platform token — making most Chrome UA strings identical to each other regardless of the exact OS version or Chrome build. The replacement is the User-Agent Client Hints API (UA-CH), which requires a website to explicitly request individual pieces of browser information via HTTP request headers or the navigator.userAgentData JavaScript API. This opt-in model means only the data actually needed is shared, instead of broadcasting a detailed string on every request without the user's knowledge.

Canvas fingerprinting, WebGL fingerprinting, and how trackers identify you without cookies

Browser fingerprinting is the practice of combining individually non-unique data points — screen resolution, time zone, installed fonts, language list, User-Agent, touch capability, battery status — into a composite identifier that is unique enough to track you across websites without setting a single cookie. The Electronic Frontier Foundation's Panopticlick project (now Cover Your Tracks) demonstrated that a full browser fingerprint uniquely identifies approximately 83% of browsers tested, and that the fingerprint is stable across sessions even after clearing cookies or switching to private/incognito mode, because those modes only block storage mechanisms, not JavaScript API access.

Canvas fingerprinting exploits a subtle fact about GPU rendering: when a browser draws text using a specific font and colour onto an HTML5 Canvas element, the exact pixel values of the resulting image vary slightly between different hardware and driver combinations. The same string rendered in the same font at the same size produces fractionally different anti-aliasing, sub-pixel hinting, and emoji rendering on an Intel GPU versus an Apple M-series chip versus an AMD GPU. Taking a SHA-256 hash of the pixel bitmap produces a value that is effectively a hardware fingerprint, stable across browser restarts and incognito sessions. WebGL fingerprinting goes further by querying the WEBGL_debug_renderer_info extension, which returns the exact GPU model and driver string (for example, ANGLE (NVIDIA GeForce RTX 4080 Direct3D11 vs_5_0 ps_5_0)). The renderer string alone uniquely identifies the GPU model; combining it with a rendered 3D scene result produces an extremely stable cross-session identifier tied to the physical device rather than the browser profile.

Browser vendors respond to fingerprinting pressure in different ways. Tor Browser takes the most aggressive approach: it makes every user appear identical by returning the same spoofed values for all fingerprint APIs, accepting some functionality breakage as the price of anonymity. Brave adds calibrated random noise to Canvas and WebGL output on each page load — the values change session to session but remain plausible, making fingerprinting unreliable without breaking rendering. Firefox partitions storage and some APIs per top-level site using State Partitioning. Safari's Intelligent Tracking Prevention blocks third-party access to many sensor APIs. The Privacy Sandbox project proposed Gnatcatcher (later deprecated) and ultimately settled on reducing the UA string surface and gating sensitive APIs behind Permissions Policy as the primary mitigations at the Chrome level.

How a browser actually turns HTML into pixels: rendering engines and JavaScript JITs

Every modern browser processes a web page through the same sequence of stages known as the critical rendering path. The browser parses HTML into the DOM (Document Object Model) and parses CSS into the CSSOM (CSS Object Model). These two trees are merged into a Render Tree that contains only the visible elements annotated with their computed styles. The engine then runs Layout (also called Reflow) to calculate the exact pixel position and size of every box on the page, followed by Paint, which records draw commands for each layer, and finally Composite, which hands the layers to the GPU to assemble the final frame. Modern browsers promote elements that animate or scroll onto their own compositor layers (triggered by CSS transform, opacity, or the will-change hint) so that scrolling and transitions can be handled entirely on the GPU thread without re-running Layout or Paint.

The three dominant rendering engines in use today are Blink (used in Chrome, Edge, Opera, and Samsung Internet — Blink was forked from WebKit by Google in 2013), Gecko (Firefox's engine, now with a parallel Stylo CSS engine written in Rust), and WebKit (Safari and all iOS browsers — Apple's App Store rules require all iOS browsers to use WebKit, making Safari's engine the only rendering engine legal on iOS). The JavaScript engines that sit alongside each renderer are equally differentiated: Google's V8 (used in Chrome, Edge, and Node.js) introduced the first modern JIT compiler architecture and today uses a multi-tier pipeline — the Ignition interpreter collects type feedback, TurboFan compiles hot functions to optimised native machine code, and Maglev handles the middle tier. Mozilla's SpiderMonkey (Firefox) built the first JavaScript JIT compiler in 2008 and today also uses a tiered system. Apple's JavaScriptCore (also called Nitro) powers Safari and similarly uses a four-tier pipeline from interpreter through DFG and FTL JIT compilers.

Chrome's multi-process architecture is one of the most consequential browser design decisions of the past two decades. Each renderer process runs in a sandboxed OS process with minimal OS privileges, so a crash in one tab cannot corrupt the memory of another. The browser kernel process brokers privileged operations (file access, network, UI) on behalf of sandboxed renderers. A separate GPU process handles all graphics commands. The 2018 disclosure of the Spectre and Meltdown CPU vulnerabilities — which allow a running process to speculatively read memory from other processes — accelerated the deployment of Site Isolation, which ensures that pages from different origins are always placed in different renderer processes. This means that a malicious script on evil.example cannot use a Spectre timing attack to read the DOM or cookies of a simultaneously open bank.example tab, because they physically reside in different OS-level memory spaces that the CPU's speculative execution cannot cross.