Before you start
Separate the claim from the measurement. Webcam resolution as printed on a box is a marketing statement about a sensor mode. What an application receives is the result of a negotiation, and the two are only equal when every layer in between agrees.
Record the current state before changing anything: which application, which selected camera, and what the delivered stream actually is. Without that baseline you cannot tell whether a later change helped.
Close other camera users first, because concurrent use is the single most common reason a webcam resolution is downgraded rather than the stream being refused outright.
Run the check
Open the webcam test and read the delivered settings from the active track. MediaStreamTrack.getSettings reports the mode after negotiation, and that is the only webcam resolution figure worth trusting. Requested constraints are a wish, and they remain in the request object even when the camera ignored them entirely.
Note width, height, frame rate and aspect ratio together. A camera constrained by bandwidth often drops resolution; one constrained by light drops frame rate; one falling back to a different sensor mode changes aspect ratio. Those three signatures point at different causes.
Now change exactly one condition and re-read. Close the other application that was using the camera, or move from a USB hub to a direct port, then reopen the stream. If the delivered mode improves, you have identified the constraint without touching a driver.
If the mode is still low, try a second browser. Engines differ in how they choose default constraints, and a camera that opens at 1080p in one and 480p in another has told you the limitation is software, not hardware.
Read your result
USB bandwidth is the classic cause. Uncompressed 1080p30 needs far more bandwidth than a shared hub can provide, and cameras negotiate down rather than fail. Anything else drawing from the same controller — an external drive, another camera, a capture device — competes for the same budget.
Concurrent use is next. When a second application already holds the camera, some systems offer a reduced shared mode instead of refusing access, which is why a stream can be simultaneously working and disappointing.
Application constraints come third. Conferencing clients frequently cap resolution deliberately to protect bandwidth and CPU, and no camera setting will override a cap applied downstream of the capture.
Measurement limits
The browser reports the negotiated stream, not the sensor's capability. It cannot prove that a camera supports 1080p, only that this stream is or is not carrying it. A camera that never delivers the mode anywhere may simply not have it, regardless of the box.
Compression is invisible at this layer. A 1080p stream that has been heavily compressed by the camera's own encoder reports 1920×1080 and still looks soft, because resolution and image quality are different properties.
What a call participant sees is negotiated again by the conferencing service after this point, based on network conditions. A perfect local 1080p stream can still arrive as 360p at the other end.
What to do next
If the higher mode opens after another application closes, the camera is not missing that mode and no driver work is warranted. Make quitting the other application part of your routine instead.
If a direct USB port fixes it, the hub was the constraint. Keep the camera on a dedicated port, ideally not shared with storage or capture hardware.
If no combination produces the advertised mode in any browser or application, that is now a hardware or firmware conclusion and worth raising with the manufacturer — with the delivered track settings as your evidence.
Symptom table
| Symptom | Likely layer | Next action |
|---|---|---|
| 1080p request delivers 640×480 | Negotiation or concurrent use | Read track settings and close other camera users |
| Aspect ratio changes | Fallback mode selection | Compare supported modes and application constraints |
| Frame rate falls at higher size | Bandwidth or exposure tradeoff | Compare frame rate at each negotiated mode |
Common questions
Why is my 1080p webcam sending 640x480?
Something downstream negotiated it down: another application holding the camera, a shared USB hub running out of bandwidth, or the calling application capping resolution on purpose. Close other users and use a direct port first.
How can I check what resolution my webcam is really sending?
Read the active track's settings rather than the constraints anyone requested. A browser webcam test shows the negotiated width, height and frame rate, which is the only number that reflects reality.
Does a higher resolution always look better on a call?
No. Lighting usually matters more, and conferencing services re-encode the stream to fit the network anyway. A well-lit 720p picture routinely beats a dim 1080p one.