Press start · grant permission once · nothing leaves this page
safe · secure · no server · works offline · fast
…or paste a file you copied in Finder, or just start typing at the cursor.
↓ scroll for about & FAQ
Most “test my webcam” pages show you a mirror. This one shows you
the mirror and the paperwork — the
Mirror tab is literally
the mirror, and the other three are the paperwork. When a page opens a
camera, the browser
answers three different questions with three different objects, and they
routinely disagree with each other:
getConstraints() is what was asked for,
getCapabilities() is what the hardware says it can
do, and getSettings() is what the track actually
got. Ask for 1920×1080, watch the camera report that it
supports 1920×1080, and receive 1280×720 anyway — because
another application already opened it, or the driver preferred a different
mode. No browser UI anywhere puts those three side by side. The
Capabilities tab does, and highlights every row where the ask
and the result disagree.
Open this route and, before any permission prompt, it can already tell you how many cameras are attached — but not what they are called. Device labels stay empty until you grant access. That gap is a deliberate browser mitigation, and it is much easier to believe once you have watched the names appear the instant you press allow. The same tab counts the distinguishing facts readable off your camera stack: the number of devices, the maximum resolution and frame rate, and every optional control your hardware exposes. We report that as a count with the list behind it rather than an entropy figure in bits — a real entropy estimate needs a population distribution nobody has, and inventing one would be scare-copy.
The Transform tab records a short clip of the picture you are actually looking at — your effect, not the raw camera — and hands the bytes straight to the toolkit that reads them: an MP4 opens in /mp4 with its whole atom tree. Nothing is written to disk on the way, and nothing is uploaded — there is no server to upload to. The interesting part is what the recording lacks: no EXIF, no GPS, no camera make, model or serial. It is the exact inverse of the usual OmniViewer story, where a video off your phone arrives dense with identity and our metadata tools help you strip it. Take one of each and compare them.
A camera is the opposite problem to a 20 GB file. A file is enormous and
arrives slowly; a camera is small and arrives forever — 1080p at
30 fps is roughly 93 MB of raw pixels every second, more than any file
this site opens. So the preview is the browser’s own <video>
element pointed at the MediaStream, and the frames never pass through JavaScript
at all. A still is one canvas read, encoded and released immediately. A clip is
capped at 30 seconds and encoded incrementally by MediaRecorder, so
memory stays flat. The
deep dive
walks through all of it, including the four different depths at which a browser
will hand you the bytes coming off a camera.
Because every effect is editable source rather than a fixed filter, the Transform tab doubles as a classroom: Pixelate is a mean over a block, Posterize is rounding to a grid, Twirl is a conversion to polar coordinates and back, and each one is a three-line change with your own face attached to the result. The one number each effect turns on is a slider on the picture, so “what does the block size do” is a drag rather than an edit — and the drag writes the new value into the code, where the class can still read it. Learn maths and programming with a photo booth is the lesson plan — six effects, the arithmetic behind each, exercises with answers, and a 45-minute outline.
OmniViewer opens every file format, powered by the same viewing engine as fastjsonviewer.com and hugecsv.com.
No. OmniViewer is a static page with no server-side processing and no analytics of the video: the stream goes from your camera to the page and nowhere else. There is no endpoint to upload to. Clips you record are held in your browser tab and disappear when you leave, unless you download them yourself.
No. Nothing opens until you have granted this site camera access, and the grant is yours to make in the browser’s own prompt. What happens after that is different: once the permission exists, the Mirror and Transform tabs — the two that are nothing but a picture — open the camera on arrival rather than making you press start again every visit. The page checks whether the permission is already there without prompting for it, using the Permissions API where the browser supports the name and the presence of device labels everywhere else. Press stop and it stays stopped, and revoking the permission in your browser puts the button back.
The highest one your camera reports it can do. A camera’s real maximum is only readable from a track that is already open, so the first stream on a device is opened with no size constraint and then raised to the maximum getCapabilities() reports — one applyConstraints on the live track, no second permission prompt. The resolution picker on the Preview tab overrides it: pick a specific size, or “Camera’s choice” to send no width or height at all and see what the device volunteers on its own, which is usually a good deal less.
Because a constraint is a request, not a command. An "ideal" constraint is a preference the browser may silently ignore, and a camera already opened by another application will hand you whatever mode it is already running in. The Capabilities tab is built to show exactly this: the resolution you asked for, the range the hardware reports it supports, and the one you actually got, with the disagreement flagged.
Device labels are hidden until you grant camera access. Before the grant, a page can enumerate your devices and count them but cannot read their labels — that is a deliberate browser privacy mitigation. Press Start camera and allow access, and the names appear immediately. You can watch it happen on the Capabilities tab.
The preview and the asked/supported/got table work in any modern browser on a secure (https) page. How much the table has to show depends on the browser and the hardware: Chromium reports the widest set of camera controls, and most laptop webcams expose far fewer of them than a phone camera does. The effects need a Web Worker, and recording a clip of them needs both canvas captureStream and MediaRecorder.
Whatever the browser supports, preferring MP4 — Safari and Chrome 130+ record MP4, which opens in OmniViewer’s /mp4 toolkit with its full atom tree. Browsers that only record WebM produce a valid file that opens in the universal raw, hex and strings views, since OmniViewer has no dedicated WebM route yet. Clips are capped at 30 seconds so the recording stays in memory safely.
No, and that is half the point of recording them here. A browser capture has no camera make or model, no lens or firmware string, no serial number and no location — the capture path has no access to any of it. One line is added on the way out naming the website that made the file, and the toolkit that reads it will take even that out. Open a clip in /mp4 and compare it against a video from your camera roll to see the difference.
No. Stopping the camera stops every track, which is what turns the hardware indicator light off; loading a file, pressing close, or leaving the route all do the same. Merely dropping the video element would leave the light on, so the toolkit stops the tracks explicitly.