Camera Capabilities Inspector

See, request, and control everything your browser exposes about a camera

Camera Lab

100% local. Uses getUserMedia, MediaStreamTrack, ImageCapture, MediaRecorder and WebCodecs directly in your browser. No frames, photos or device details leave your device.
Camera is off. Build a request in the Request tab or just press Start camera.

Delivered frame

--

Settings

--

Measured FPS

--

Dropped / total

--

Capture to paint

--

getUserMedia time

--

First frame

--

Track state

--

These values build the getUserMedia() constraints. Changing them requires a restart: press Start camera again. Leave a value empty to not constrain it.

Extra flags

Resulting getUserMedia() argument

Edit freely; your text is used as-is when you press Start.

Controls are generated from track.getCapabilities(): everything the browser exposes for this camera appears here, including non-standard keys. Changes are sent with applyConstraints() without restarting the session.

Refresh

Start the camera to see its live controls.

Raw applyConstraints()

Prefilled with track.getConstraints(). Note: applyConstraints replaces the whole constraint set.

Track

No active track.

Requested vs. actual

Every key from getConstraints(), getSettings() and getCapabilities() side by side.

KeyRequestedActual (settings)Capability
No active track.

Raw JSON

--

redEyeReduction

PhotoCapabilities / PhotoSettings

--

Canvas snapshot (works everywhere)

No capture yet.

Resolution probe

Requests each size with exact width/height on the current camera and records what is actually delivered. Enable resizeMode: none to see native sensor modes instead of browser-scaled output.

Options

Probe results
Run a probe.

MediaRecorder

No recording yet.

MediaRecorder.isTypeSupported()

WebCodecs VideoEncoder.isConfigSupported()

Checked at the current track resolution (or 1280x720 when the camera is off), for hardware and software preference.

Codecprefer-hardwareprefer-software
Not checked yet.

Browser & platform

API support

Permissions

navigator.mediaDevices.getSupportedConstraints()

Green = the browser recognizes the constraint name. Unknown names are ignored by getUserMedia. This says nothing about whether the current camera supports it -- see the Track tab for that.

Devices (enumerateDevices)

KindLabeldeviceId / groupId

  

How to Use the Camera Capabilities Inspector

  1. Start the camera. Press Start camera with the default request, or build a specific request in the Request tab (device, facing mode, width, height, frame rate, aspect ratio, resizeMode, pan/tilt/zoom permission, arbitrary extra constraints). The exact JSON passed to getUserMedia() is shown and editable.
  2. Compare requested vs. actual. The Track tab lists every key from getConstraints(), getSettings() and getCapabilities(). Differences show immediately whether the browser honored, clamped, or ignored a request.
  3. Turn the knobs. The Live controls tab builds a slider, dropdown, or toggle for every capability the track reports -- zoom, pan, tilt, focus mode and distance, exposure mode, time and compensation, ISO, white balance and color temperature, brightness, contrast, saturation, sharpness, torch, background blur, face framing and anything else your browser adds.
  4. Probe the hardware. The Probes tab scans standard resolutions and frame rates, checks whether several cameras can run at the same time, and reads a raw VideoFrame (pixel format, coded size, color space).
  5. Test capture paths. Take photos with the ImageCapture API, grab frames, create canvas snapshots, record with MediaRecorder, and check which WebCodecs encoders are available.
  6. Export. Download or copy the JSON report and attach it to a bug ticket so everybody sees the same browser, device, capability and probe data.

Why Camera Behavior Differs Between Browsers and Devices

The same web app can get very different camera behavior on two phones, or on the same laptop in two browsers. The browser sits between your code and the camera driver and decides which controls to expose, how to map a request to a hardware mode, and whether to scale frames in software.

Constraint support is layered. getSupportedConstraints() only says which names the browser understands. getCapabilities() says what the current track can do, which depends on the camera, the operating system camera stack, and the browser. getSettings() says what is really active. A request can therefore be understood, accepted, and still not applied.

Resolution requests are negotiated. With the default resize behavior, Chromium can crop and downscale a larger native mode to match almost any width and height. That is convenient, but it hides the real sensor modes and costs CPU. Requesting resizeMode: "none" reveals the native modes. Frame rate is similar: the configured value is an upper bound, and in low light many cameras extend exposure time and deliver fewer frames than configured -- the measured FPS readout shows this.

Image controls come from a separate spec. Zoom, focus, exposure, white balance, torch, and pan/tilt are defined in the Media Capture Image specification. Support ranges from full manual control on some Android phones and UVC webcams to nothing at all. Mobile operating systems also add platform effects such as background blur or face framing that the browser may expose as read-only or toggleable constraints.

Some changes need a new session. Switching cameras, choosing facing mode on many phones, adding an audio track, or asking for pan/tilt/zoom permission happens in getUserMedia(). Most image controls, and often resolution, can be changed later with applyConstraints().

Constraint Cheat Sheet

ConstraintTypeTypical use
width / heightnumber rangeFrame size in pixels. Combine with resizeMode to control scaling.
frameRatenumber rangeMaximum frames per second the camera is configured for.
aspectRationumber rangeWidth divided by height, e.g. 1.7778 for 16:9.
facingModestring listuser, environment, left, right -- front or back camera on phones.
resizeModestring listnone (native modes) or crop-and-scale (browser may scale).
zoom / pan / tiltnumber rangeOptical or digital zoom and PTZ camera movement. Request pan: true etc. at start for permission.
focusMode / focusDistancelist / rangenone, manual, single-shot, continuous; distance in meters when manual.
exposureMode / exposureTimelist / rangeManual exposure time is in units of 100 microseconds.
exposureCompensation / isonumber rangeExposure bias in EV and sensor sensitivity.
whiteBalanceMode / colorTemperaturelist / rangeManual white balance in Kelvin.
brightness / contrast / saturation / sharpnessnumber rangeDriver image processing controls, common on UVC webcams.
pointsOfInterestlist of {x, y}Normalized points for focus and metering, 0..1.
torchbooleanTurns on the flash LED continuously (mostly rear phone cameras).
backgroundBlur / faceFraming / eyeGazeCorrectionboolean listPlatform camera effects exposed by some operating systems.

Related Tools

Privacy & Limitations

  • Client-side only. No frames, photos, recordings, device names or reports are sent anywhere. Nothing is stored after you leave the page.
  • Reported values come from the browser. The tool shows what the browser exposes; the hardware may support more than the browser passes through.
  • Probes change the stream. Resolution and frame-rate probes reconfigure the camera; the original request is restored afterwards.
  • Requires a secure context. Camera access needs HTTPS or localhost.

Related Tools

View all tools

Camera Capabilities Inspector FAQ

What is the difference between getCapabilities, getSettings, and getConstraints?

getCapabilities() returns the range or list of values the browser says the camera track can take (for example zoom 1 to 10 in steps of 0.1). getSettings() returns the values that are actually in effect right now. getConstraints() returns the constraints you last requested via getUserMedia or applyConstraints. Comparing all three is the fastest way to see whether a request was honored, clamped, or silently ignored.

Why does my camera not report zoom, focus, exposure, or torch?

These advanced image constraints come from the Media Capture Image specification. The browser only exposes them if it implements that part of the spec and the camera driver passes the controls through. Chromium-based browsers expose the most, especially on Android and with UVC webcams on desktop. Other browsers often expose only width, height, frame rate, aspect ratio, and facing mode. This tool lists exactly what your browser reports, so you can compare devices and browsers.

Why did applyConstraints succeed but the value did not change?

Values inside the advanced array are optional: if a set cannot be satisfied it is skipped without an error. Ideal values are also only a preference. Only exact, min, and max constraints raise an OverconstrainedError. Some controls also depend on others; for example exposureTime usually needs exposureMode set to manual, and focusDistance usually needs focusMode set to manual first. The tool shows the requested value next to the value actually in effect after every apply.

Why do I get OverconstrainedError?

An OverconstrainedError means at least one exact, min, or max constraint cannot be satisfied by any available camera mode. The error object names the constraint that failed. Switch that constraint to ideal, relax it, or use the resolution and frame-rate probes to discover which values the camera really supports.

Does the camera really support every resolution the browser returns?

Not necessarily. Chromium can crop and scale frames to match a requested size, so almost any resolution appears to work. Set resizeMode to none (enabled by default in the resolution probe when supported) to ask only for native camera modes. The probe then shows which sizes the camera delivers directly and which requests fall back to a different size.

Why must the camera session be restarted for some changes?

Some properties, such as the device, the facing mode on many phones, the audio track, or requesting pan/tilt/zoom permission, can only be chosen when getUserMedia opens the camera. Others, such as zoom, exposure, focus, or even resolution on many devices, can be changed on a running track with applyConstraints. The Request tab restarts the session; the Live controls tab changes the running track.

Is any video or device information uploaded?

No. Everything runs locally in your browser with standard Web APIs. Frames, photos, recordings, device names, and the JSON report never leave your device unless you copy or download them yourself. Stopping the camera ends every track and releases the hardware.

Why are device labels empty before I start the camera?

Browsers hide device labels, and sometimes the full device list, until the page has camera permission. After you start the camera once, the device list, labels, group IDs, and per-device capabilities become available.

Request a New Tool
Improve This Tool