Camera Resolution Test

Introduction

The DeviceHub Camera Resolution Test reveals the actual capture dimensions your browser and camera negotiate, not the resolution printed on retail packaging or listed in a spec sheet. Marketing stickers often claim 1080p, 2K, or 4K, yet conferencing stacks, USB bandwidth limits, driver defaults, thermal throttling, and browser constraint policies can settle on a smaller frame than buyers expect. This free browser tool starts a video track with getUserMedia, then reads width and height from MediaStreamTrack.getSettings() so you see precisely what web applications are likely to receive during a call or recording session. Remote workers preparing for HD client meetings, students verifying proctoring requirements, streamers validating a new USB webcam, and support teams diagnosing blurry-video tickets get a concrete pixel readout without installing Logitech G Hub, OBS, or vendor-specific utilities. The readout reflects negotiated capture size rather than how large the preview appears on screen, which prevents CSS scaling from misleading you. Pair this page with the full Webcam Test when you need both objective numbers and a subjective look at sharpness, focus, and compression artifacts in real time. Support engineers often ask for getSettings() screenshots during tickets, this page produces that evidence without third-party screen recorders.

What this tool does

The tool requests camera access through getUserMedia, opens an active video MediaStream, and displays the selected track's reported width and height pulled directly from getSettings(). It focuses on negotiated capture resolution rather than the CSS display size of the preview element, which can be scaled, letterboxed, or cropped independently by layout rules. When the browser exposes them, related settings such as frameRate and aspectRatio may appear alongside dimensions so you can see whether the engine traded pixels for smoother motion during negotiation. Device selection lets you compare a laptop's integrated sensor against an external webcam on the same machine under identical lighting. Stopping the test ends all tracks cleanly so the camera indicator extinguishes. The goal is an unambiguous answer to the question every support thread asks: what resolution is my browser actually capturing right now, in pixels, for this specific device and tab? Reading getCapabilities() max width and height when exposed helps you understand headroom above the active getSettings() pair without guessing from marketing materials alone.

When to use it

Run this test when a meeting platform looks soft despite owning a so-called 1080p camera, when you just bought a new webcam and want proof the browser can open a high mode, or when corporate policies or browser flags might cap capture size below hardware maximum. Use it after docking through a USB hub that may reduce available bandwidth, after switching between front and rear phone cameras, and when comparing Chrome versus Firefox versus Safari on the same hardware to document engine differences. Exam platforms, hiring tools, and telehealth portals sometimes require a minimum resolution threshold, this page provides an independent check before you enter a high-stakes session where device lock-in prevents switching mid-call. Content creators comparing 720p versus 1080p for streaming bitrate planning benefit from knowing the true upstream dimensions. IT staff validating corporate laptop imaging also use pixel readouts to confirm driver bundles expose expected modes to the web platform rather than only to native apps.

How it works

After getUserMedia resolves with a video constraint, the page inspects the first video MediaStreamTrack attached to the returned stream. MediaStreamTrack.getSettings() returns the currently applied configuration object, including width and height integers when the browser exposes them for that track. Those values reflect the negotiated capture resolution for this session, not necessarily the maximum listed in getCapabilities(), which describes supported ranges the device claims it can honor via applyConstraints(). Ideal width and height values in the getUserMedia constraint object can influence negotiation, but browsers may clamp requests based on hardware limits, other open tracks, power policies, and privacy guardrails. The HTMLVideoElement preview may letterbox or scale via CSS object-fit rules; the resolution readout still comes from track settings so display styling cannot fake a higher capture size. On mobile, orientation changes may cause getSettings() to report swapped dimensions until the track renegotiates. Some engines expose resizeMode or aspectRatio hints alongside pixel counts. Comparing getSettings() after a cold start versus after another app released the camera often explains sudden resolution jumps. Secure HTTPS context is mandatory for camera access in all major engines, and permission must be granted before labels and some settings populate reliably through enumerateDevices. When applyConstraints requests ideal width values, watch getSettings() after renegotiation completes because some drivers apply new modes only after a brief pause in frame delivery.

Step-by-step instructions

1. Navigate to the Camera Resolution Test page on DeviceHub and click the Start button to begin the measurement session, ensuring you are on HTTPS or localhost so navigator.mediaDevices.getUserMedia is available in your browser without insecure-context blocks.
2. Allow camera permission when the browser dialog appears, because without grant the page cannot open a live MediaStreamTrack whose getSettings() object contains meaningful width and height integers for your selected sensor.
3. Select the specific camera you intend to use for meetings or recording from the device list if more than one videoinput is enumerated after permission is granted through mediaDevices.enumerateDevices().
4. Wait until the preview shows a live moving image with stable exposure, then read the reported width and height values displayed from MediaStreamTrack.getSettings() rather than inferring resolution from CSS-scaled preview dimensions.
5. Optionally switch to a second camera or reconnect through a different USB port on a powered hub and compare negotiated sizes side by side across separate runs to spot bandwidth limits or driver default differences.
6. Click Stop when you finish measuring so track.stop() releases the sensor, the OS camera indicator turns off, and other applications such as Zoom or OBS can open the device without NotReadableError conflicts. If numbers still look low, close conferencing apps, unplug USB hubs, and rerun Start for a clean negotiation.

Common problems

Lower-than-expected resolution often means another process is sharing the camera, a USB hub is bandwidth-limited for dual high-mode streams, or the browser defaulted to a power-saving profile on battery power. Some integrated cameras advertise high modes in marketing materials but only expose modest sizes to the web platform through conservative drivers that reserve full modes for native apps. Mobile browsers may report different dimensions for front versus rear lenses or after rotation because facingMode and screen orientation change negotiation mid-session. If readings stay blank or show zero dimensions, the track may not be live yet, wait for an active stream before calling getSettings(). Virtual cameras, OBS virtual cams, and beauty-filter utilities can advertise unusual or fixed dimensions; disable them temporarily for a hardware baseline. Remember that getCapabilities() maximums are aspirational until you successfully applyConstraints and confirm the new settings stick in a follow-up getSettings() read. Corporate VDI sessions may report capped dimensions unrelated to physical webcam capability, compare on bare metal when possible.

Privacy explanation

Resolution values are derived locally from your live MediaStreamTrack settings object and never leave your browser session as uploaded video or telemetry beacons. Frames displayed in the preview are rendered on-device only; DeviceHub servers do not receive pixel buffers or store dimension logs tied to your identity or hardware serial numbers. The tool needs camera permission solely to open a short-lived stream for measurement, and you can stop capture immediately when finished through the Stop control. Revoke site camera access anytime through browser settings if you prefer not to retain grant for this origin after troubleshooting completes. No historical resolution chart is persisted remotely when you close the tab.