Screen Information

Introduction

The DeviceHub Screen Information tool is a free online screen geometry diagnostic that reports screen width and height, available workspace area (availWidth/availHeight), color depth or pixel depth, pixel orientation signals, and related screen object fields the browser exposes, without taking over Display Information’s job of gamut, HDR media, isExtended, and refresh-rate hints, and without replacing Screen Resolution’s browser-category layout viewport narrative. Designers checking panel CSS pixels, IT imaging dual-monitor desks, support capturing orientation bugs, QA validating kiosk fullscreen available area, and educators separating taskbar-excluded avail sizes from full screen sizes all benefit. DeviceHub draws a bright line: screen means geometry; display means capability media queries and multi-screen hints elsewhere. Cross-link Screen Resolution when the ticket is mostly responsive CSS viewport versus screen. Cross-link Display Information, HDR Test, Refresh Rate Test, and Display Aspect Ratio Test when the question is visual capability, not duplicate those drills here. Pair with Device Information for hub context including DPR and touch. Permissions none, geometry APIs are not camera flows. Marketing 4K labels still yield to OS scaling. Mobile browser chrome affects viewport more than screen.width sometimes, read both Screen Information and Screen Resolution carefully. DeviceHub does not read EDID product names. Schools should teach avail versus screen as “usable desktop versus full screen object.” Docked laptops flipping between lid and external monitors change numbers when the window moves, capture after placing the window correctly. Hardware-category information architecture needs a geometry home that is not the Browser Screen Resolution article and not the Display capability essay. Screen Information fills that slot with screen object vocabulary: width, height, available workspace, color depth, and orientation, plus explicit redirects when users actually wanted viewport layout storytelling or HDR gamut flags. IT departments imaging multi-monitor trader desks capture avail heights to explain why maximized apps sit under taskbars differently per OS. Kiosk integrators verify fullscreen available area before locking browsers. Mobile teachers rotating loaner tablets watch orientation type flip live. Design QA comparing CSS pixels to retail 4K labels finally has Hardware-suite language matching DeviceHub’s Screen versus Display rule. Cross-link Screen Resolution when SEO intent is classic resolution layout checks in Browser. Cross-link Display Information, HDR Test, Refresh Rate Test, and Display Aspect Ratio Test when capability or visual proof is required, do not reinvent those UIs here. Pair with Device Information when DPR and touch join geometry in one hub paste. Permissions remain none. DeviceHub does not parse EDID product names or serials. Docking station drama is solved by moving the window first. Schools teaching CSS pixels versus device pixels can keep DPR teaching on Device Information or Screen Resolution to avoid triple repetition while still mentioning adjacency. Projector carts in lecture halls often report surprising sizes when OS scaling is ignored, capture scaling percent beside screen.width every time.

What this tool does

Screen Information reads the screen object and related orientation APIs, presents width, height, availWidth, availHeight, colorDepth/pixelDepth, and orientation type when available, and explains geometry versus display-capability scope. It does not run dead-pixel patterns, does not measure Hz visually, and does not claim DCI-P3 certification. Compared with Screen Resolution, this Hardware article emphasizes screen/avail/depth/orientation vocabulary and Hardware-suite navigation; Screen Resolution remains the Browser tool optimized for screen, window, and viewport trio storytelling. Live updates on resize/orientation help mobile testing. Permissions none. Dual-monitor users are told to move the window. Notes redirect HDR curiosity to Display Information. DPR may be mentioned as adjacent but Device Information/Screen Resolution own richer DPR teaching to avoid triplication. Screen Information presents screen.width, screen.height, availWidth, availHeight, colorDepth or pixelDepth, and orientation details when APIs exist, with live refresh on resize and orientation change where listeners apply. It explains that avail metrics often exclude OS chrome on desktop while mobile browsers may report avail equal to screen. It refuses to run dead-pixel or Hz tests. It points HDR and gamut seekers away quickly. Relative to Screen Resolution, the Hardware framing emphasizes screen/avail/depth/orientation and suite navigation rather than the full window-and-viewport trio deep dive, though cross-links encourage opening Screen Resolution when that trio is the ticket. Permissions none. Dual-monitor instructions are first-class. Emulation warnings appear so DevTools fake screens do not become RMA evidence. Notes mention DPR lives primarily on sibling pages to reduce duplication while acknowledging users will ask.

When to use it

Use Screen Information when avail area versus full screen matters (taskbars, docks), when color depth rows are requested, when orientation API behavior is under test, and when Hardware-category IA should own geometry deep links. Prefer Screen Resolution for classic “what is my resolution” layout SEO intent in Browser. Prefer Display Information for gamut/HDR/isExtended/refresh hints. Prefer HDR Test or Refresh Rate Test for visual proof. Prefer Display Aspect Ratio Test for aspect drills. Prefer Device Information for a combined hub. Avoid EDID warranty claims. Avoid assuming colorDepth 24 proves HDR. Move the window to the correct monitor first. Retest after scaling changes. Use in kiosk setup guides. Use when avail versus screen is the dispute, when color depth is requested in hardware questionnaires, when orientation events misbehave in your app, and when docs should deep-link a Hardware geometry URL. Prefer Screen Resolution for layout viewport SEO journeys. Prefer Display Information for gamut/HDR/isExtended/refresh hints. Prefer visual Display tools for human judgment. Prefer Device Information for combined hubs. Avoid EDID claims. Avoid Hz claims. Move windows to the correct display. Retest after scaling changes and after connecting docks. Use in kiosk runbooks and digital signage browser setup guides.

How it works

Browsers expose screen.width/height in CSS pixels for the screen of the window. avail* subtracts OS UI chrome in many desktop implementations. colorDepth/pixelDepth describe bit depth hints, not HDR metadata. screen.orientation provides angle/type when supported. These are geometry and simple depth signals, not Window Management getScreenDetails full multi-display permissioned labs, which Display Information discusses only at honesty level without requiring permissioned extended screens for the default none readout. DeviceHub permissions stay none. Secure HTTPS. No server geometry upload on view. Fingerprinting uses screen sizes historically, copy carefully. VisualViewport remains more viewport than screen, Screen Resolution covers that trio better. Hardware page keeps focus on screen object semantics and Hardware cross-links. The Window screen property exposes metrics for the display associated with the browsing context’s window. CSS pixels dominate, so OS scaling changes numbers relative to marketing native mode. avail* subtracts system UI in many desktop agents. colorDepth historically related to bit depth of the output; it is not HDR metadata and not proof of wide gamut, Display Information owns gamut media queries. screen.orientation provides type and angle with lock APIs existing separately for apps; this diagnostic reads, it does not lock orientation. DeviceHub permissions stay none; we do not request Window Management permission for full multi-screen detail dumps on this page. Secure HTTPS. Local display only, no geometry upload on view. Fingerprinting history makes screen sizes sensitive; copy carefully. VisualViewport and layout viewport nuances remain better taught on Screen Resolution. Hardware content keeps Screen versus Display boundaries crisp for maintainers.

Step-by-step instructions

1. Drag the browser to the monitor under test, set zoom 100%, and open Screen Information over HTTPS.
2. Record screen width/height and avail width/height, noting taskbar differences on desktop OS.
3. Note color depth and orientation; rotate phones to validate orientation updates.
4. Open Screen Resolution when you also need window and layout viewport rows in Browser framing.
5. Open Display Information or Display category tests when gamut, HDR, refresh, or aspect capability is the real question.
6. Label figures as CSS-pixel screen geometry in tickets, including OS scaling percentage.

Common problems

Scaling mismatches versus 4K marketing. Wrong monitor on multi-display. Avail equals screen on some mobile browsers, taskbar concept differs. Color depth 24 expected everywhere. Orientation stuck until rotate completes. Emulation faking screen. Remote agent opening page. Confusing viewport height with screen.height on mobile. Expecting Hz here, use Refresh Rate Test. Expecting P3 gamut here, use Display Information/HDR Test. Fullscreen games unrelated to browser screen object. Projector overscan not reflected as EDID crop. 4K marketing versus scaled CSS pixels. Wrong monitor selected. Avail equals screen on mobile confusing desktop-centric docs. colorDepth 24 expected as HDR. Orientation lag until gesture completes. DevTools emulation. Remote agent mistakes. Viewport height confused with screen.height. Users hunting Hz, send to Refresh Rate Test. Users hunting P3, send to Display Information or HDR Test. Fullscreen games irrelevant. Projector overscan invisible to screen object. Mixed DPI docks. Assuming depth proves ten-bit panels.

Privacy explanation

Screen dimensions fingerprint. DeviceHub shows locally, no ad upload on view. Permissions none. Prefer minimal public pastes. Tab close ends listeners. We do not request privileged multi-screen permission for basic geometry. Dual-monitor details increase entropy, share carefully. Classroom: discuss historical fingerprinting with screen sizes. Screen sizes fingerprint. DeviceHub displays locally, no ad upload on view. Permissions none. Minimize public pastes. Tab close ends listeners. No privileged multi-screen prompt for basic geometry. Dual-monitor entropy is real, share carefully. Classroom: historical fingerprint scripts used screen dimensions; modern privacy modes may round or alter values, document anomalies as policy, not DeviceHub bugs.