Camera Aspect Ratio Test

Introduction

The DeviceHub Camera Aspect Ratio Test detects the aspect ratio of your active camera stream so you know whether capture is closer to widescreen 16:9, classic 4:3, square 1:1, or another negotiated shape that affects framing in meetings and recordings. Soft cropping applied by meeting user interfaces and CSS object-fit rules on preview elements can hide the true sensor framing, leaving presenters puzzled when heads look clipped or shoulders disappear unexpectedly. This tool derives ratio directly from MediaStreamTrack width and height reported in getSettings(), separating capture geometry from how the page layout displays video on screen. Educators fitting whiteboards into frame, mobile users flipping between portrait and landscape, webinar hosts pairing slides beside camera tiles, and developers debugging constraint negotiation all get a concrete shape answer without installing native camera utilities. It complements the resolution test on DeviceHub: pixel counts tell you size, while aspect ratio tells you proportions and whether your face fits naturally inside the negotiated window. Developers filing aspectRatio constraint bugs against Chromium or WebKit use this page to capture width, height, and derived ratio from getSettings() on reproducible hardware. Ratio labels help SEO-focused creators match thumbnail framing to in-call crop expectations without guessing from a CSS-scaled preview box alone.

What this tool does

The page opens a camera stream through getUserMedia, reads negotiated width and height integers from MediaStreamTrack.getSettings(), and computes an aspect ratio classification such as 16:9, 4:3, or a numeric decimal for display. A live HTMLVideoElement preview helps you correlate the computed ratio with how much headroom, shoulder space, and background width you actually see in practice. Device selection supports comparing a modern 16:9 UHD webcam against an older 4:3 integrated module on the same PC under identical seating. The tool observes the active stream's shape rather than permanently rewriting camera modes through applyConstraints unless the underlying implementation offers that separately. Stopping releases all tracks. Use it when the recurring question is why you appear cropped or pillarboxed despite a seemingly normal preview container on the page. Stopping the stream via track.stop() ends measurement immediately so ratio readouts do not continue updating after you leave the tool panel. Numeric width÷height quotients display alongside friendly ratio classes so ultra-wide or unconventional sensors still communicate shape when labels do not fit standard buckets.

When to use it

Use this test before webinars where slides sit beside your face and assume widescreen layout, when configuring virtual backgrounds that expect 16:9 mats, when a phone camera suddenly looks taller after an operating-system update, and when comparing browsers that may pick different crop modes from the same sensor. Product photographers, document scanners repurposing a webcam, and accessibility testers verifying consistent framing across devices also care whether the stream is wide or boxy. Run it after applying width or aspectRatio constraints elsewhere to confirm negotiation results rather than assumptions. If you only need frames-per-second smoothness or permission status, use those dedicated tools instead. Combine with Multi Camera Test when two lenses may expose different native aspect ratios simultaneously on a creator desk setup. Accessibility testers verifying headroom for caption overlays and sign-language inset tiles depend on accurate aspect metadata rather than preview CSS box dimensions alone. Video editors importing browser-captured footage into timeline projects use ratio readouts to choose correct sequence presets before scaling introduces unintended letterboxing.

How it works

navigator.mediaDevices.getUserMedia returns a MediaStream containing a video MediaStreamTrack. MediaStreamTrack.getSettings() supplies width and height for the active configuration after browser and driver negotiation completes. Dividing width by height yields a numeric ratio mapped to familiar labels, for example approximately 1.777 for 16:9 or 1.333 for 4:3, with tolerance for rounding and driver quirks. Preview CSS may pillarbox or letterbox the HTMLVideoElement; that layout chrome must not be mistaken for capture ratio because the calculation uses track settings exclusively. Orientation changes on mobile can swap reported dimensions as the browser renegotiates with facingMode and screen orientation hints. applyConstraints could request an ideal aspectRatio where supported, but this diagnostic prioritizes observing the current negotiated shape transparently. HTTPS secure context and camera permission through the Permissions API gate are required before meaningful settings populate, consistent with other DeviceHub camera pages. applyConstraints with ideal aspectRatio may be supported on some devices, but this diagnostic intentionally reports the currently negotiated shape from getSettings() rather than forcing a new crop mid-test. Secure HTTPS context and Permissions API-gated camera access are required before getSettings() width and height populate reliably for ratio math on mobile and desktop alike.

Step-by-step instructions

1. Navigate to the Camera Aspect Ratio Test on DeviceHub and click Start to invoke getUserMedia with a video constraint, granting camera permission when the browser prompts for site access on this HTTPS origin.
2. Wait until the HTMLVideoElement preview displays continuous motion and the tool confirms non-zero width and height values from MediaStreamTrack.getSettings() on the active video track.
3. Read the reported aspect ratio classification alongside the underlying width-by-height pair so you understand both the friendly label and the raw numeric negotiation outcome from the browser pipeline.
4. Adjust your seating and head position within the frame to see how much vertical headroom and horizontal background space the negotiated ratio actually provides for your webinar or recording use case.
5. Switch videoinput cameras or rotate a phone between portrait and landscape orientations, then re-read getSettings() after orientation settles to compare alternate aspect ratios from the same hardware sensor.
6. Click Stop when finished so track.stop() releases the sensor, the computed ratio session ends cleanly, and background capture does not continue after you navigate away from the diagnostic tool page. Note width, height, and ratio class for support tickets before leaving.

Common problems

Users frequently confuse the HTMLVideoElement CSS layout box with true capture ratio, always trust track dimensions from getSettings() over visual padding or black bars on the page preview element during an active live capture session. Some sensors deliver 16:9 output by center-cropping a natively 4:3 imager; the web platform sees the cropped stream dimensions, not the full silicon aspect ratio from the datasheet. Virtual backgrounds, beauty filters, and OS-level touch-up can add further letterboxing inside other apps even when this test reports a clean widescreen negotiation from the raw MediaStreamTrack. If ratio flips unexpectedly after rotating a phone, wait for track renegotiation to finish before recording results for a bug report attachment to engineering. Ultra-wide webcams may not map cleanly to classic 16:9 or 4:3 labels; treat the numeric width÷height quotient as authoritative when friendly labels feel ambiguous. Zero dimensions usually mean the track is not yet live or permission was revoked mid-session, restart getUserMedia before trusting ratio output for bug reports.

Privacy explanation

Aspect ratio is calculated locally from MediaStreamTrack metadata and the live preview rendered in your browser tab without uploading frames to DeviceHub infrastructure or third-party analytics. Camera permission is consumed only while the diagnostic getUserMedia stream runs for the active measurement session on your machine. Stop the test to end capture through track.stop() and clear the hardware indicator when your operating system supports that signaling after tracks end. Computed ratio values are derived locally from track metadata and are not uploaded to DeviceHub infrastructure or stored in cookies after the session ends. Manage site permissions through browser controls whenever you want to revoke grant for this origin after completing aspect ratio checks on shared computers. Stopping capture clears the active indicator on supported systems when track.stop() runs after measurement completes on your device.