--- title: "How it works" description: "Webcamp tests your camera and microphone entirely inside your browser. Here is exactly how, and how to verify it yourself in developer tools." url: https://www.test-webcamp.com/how-it-works.html site: Webcamp updated: 2026-08-28 --- # How it works _Every test on this site runs inside your browser using standard web APIs. Nothing you see or say is transmitted anywhere. Here is the detail, so you can verify it rather than take our word for it._ ## The short version Your browser has a built-in interface for reaching cameras and microphones, called **getUserMedia**. When you press start, this page asks your browser for a media stream. Your browser asks you for permission. If you agree, the browser hands the page a live stream object, which is attached directly to the video element on the page. That stream never becomes a file and never enters a network request. It goes from your device to your browser's rendering engine and onto your screen. This site has no server-side component that could receive it even if the code tried to send it. ## How to verify this yourself 1. **Open your browser's developer tools.** Press F12 on Windows or Linux, or Command-Option-I on macOS. 2. **Switch to the Network tab** and make sure recording is active. 3. **Run any test on this site.** Let the camera run for a while and move around. 4. **Look at the requests.** You will see the page itself, the stylesheet, the script and the fonts. You will not see any outgoing request carrying video or audio data, because none is made. 5. **Read the source.** View source on any page and open the script file. It is plain, unminified JavaScript that you can read top to bottom. ## What each test actually does ### Camera Requests a video stream, attaches it to a video element, and reads the track settings for resolution and facing mode. Frame rate is measured using **requestVideoFrameCallback**, which fires once per delivered frame, so the number reflects what your camera is really producing rather than what it claims. ### Microphone Requests an audio stream and routes it into a Web Audio analyser node. The analyser gives us the raw waveform many times per second. We calculate the root mean square of that waveform, convert it to decibels, and draw the meter. The audio itself is discarded frame by frame and never accumulated. ### Speakers No permission needed and no device access at all. The tones are generated on the fly by a Web Audio oscillator and routed to the left channel, the right channel, or both, using a channel merger node. No audio files are downloaded. ### Screen Pure CSS and the Fullscreen API. The page fills the display with solid colours in sequence. Nothing is measured or transmitted; your eyes do the testing. ## What we do collect We build this the way we do for the reasons set out in [about this site](https://www.test-webcamp.com/about.html), and we take no money for recommendations, as the [disclosure](https://www.test-webcamp.com/disclosure.html) explains. Standard web server request logs record the page requested, a timestamp, your browser's user agent string and your IP address. This is what every web server records by default. We use privacy-respecting aggregate analytics to understand which pages are useful. We do not use advertising trackers, we do not build profiles, and we do not sell data. Full detail is on the [privacy page](https://www.test-webcamp.com/privacy.html). ## Why permission prompts appear Browsers require explicit consent before any website can open a camera or microphone, and they show a persistent indicator while a device is active. That is a browser-level protection that no website can bypass. It also means you have a reliable independent signal: if your browser is not showing a camera-in-use indicator, no camera is in use, whatever a page tells you. **Permissions are per-site and revocable.** Granting access here says nothing about any other site, and you can withdraw it at any moment from the icon in your address bar. Access ends the instant you close the tab. ## Browser requirements The device tests need a browser with WebRTC support, which covers every current version of Chrome, Edge, Firefox, Safari and Opera on desktop and mobile. They also require a secure connection, so the page must be served over HTTPS. This is a browser rule, not our choice: getUserMedia is unavailable on plain HTTP.