Device Types & Browsers
Which devices and browsers can run each exam configuration: a configuration-to-minimum-device map, a full capability matrix by browser engine and platform, and notes on the platform limits behind each restriction.
Configuration → minimum device
The effective floor is set by the most demanding gate or question type the exam enables:
| Exam configuration | Minimum device required |
|---|---|
| No monitoring, no lockdown | Any device with a modern browser, including phones and tablets |
| Webcam photo monitoring | Any desktop or mobile browser with a camera |
| Webcam video monitoring | Any desktop or mobile browser with a camera (includes Safari and iOS via MP4) |
| Screen recording — strict | Desktop Chrome or Edge only |
| Screen recording — relaxed | Desktop Chrome, Edge, or Firefox; Safari macOS is possible but unverified |
| Lockdown (non-relaxed fullscreen) | Any desktop browser or Android; excludes iPhone; excludes pages embedded in iframes |
| Lockdown + enforce single monitor | Desktop Chrome or Edge only |
| Audio-answer questions | Any desktop or mobile browser with a microphone |
| Video-answer questions | Any desktop or mobile browser with a camera |
| Photo-answer questions (webcam) | Any desktop or mobile browser with a camera |
| Screenshot-answer questions | Desktop browsers only (no mobile support) |
Browser and platform support matrix
The matrix is organized by browser engine, not brand. Chromium-based browsers (Opera, Brave, Vivaldi, Arc, Samsung Internet, …) inherit the column of their engine — Opera desktop follows Chrome/Edge, Samsung Internet on Android follows Android Chrome, any iOS browser follows iOS Safari. Every iOS browser (Chrome, Edge, Firefox, Opera, …) is a WebKit shell and behaves identically to Safari on iOS — Apple requires it.
| Capability | Chrome / Edge (desktop) | Firefox (desktop) | Safari (macOS) | Android — Chrome | iOS — all browsers |
|---|---|---|---|---|---|
| Webcam photo monitoring | ✅ | ✅ | ✅ | ✅ | ✅ |
| Webcam video monitoring | ✅ | ✅ | ✅ (MP4/H.264) | ✅ | ✅ (MP4/H.264) |
| Screen recording — strict (entire monitor) | ✅ | ❌ Cannot verify entire screen | ❌ | ❌ No screen API | ❌ No screen API |
| Screen recording — relaxed (any surface) | ✅ | ✅ | ⚠️ Unverified on real hardware | ❌ No screen API | ❌ No screen API |
| Microphone gate | ✅ | ✅ | ✅ | ✅ | ✅ |
| Audio answers | ✅ | ✅ | ✅ (AAC-in-MP4) | ✅ | ✅ (AAC-in-MP4) |
| Video answers | ✅ | ✅ | ✅ (MP4/H.264) | ✅ | ✅ (MP4/H.264) |
| Photo answers — webcam | ✅ | ✅ | ✅ | ✅ | ✅ |
| Screenshot answers | ✅ | ✅ | ⚠️ Unverified on real hardware | ❌ No screen API | ❌ No screen API |
| Lockdown — fullscreen | ✅ | ✅ | ✅ | ✅ | ❌ iPhone (✅ iPad) |
| Lockdown — relaxed (no fullscreen required) | ✅ | ✅ | ✅ | ✅ | ✅ |
| Single-monitor enforcement | ✅ | ❌ API not available | ❌ API not available | n/a | n/a |
Why the restrictions exist
Strict screen recording — Chrome and Edge only
Strict mode requires the candidate to share their entire monitor. It verifies this by reading the shared surface type from the browser — a piece of information only Chrome and Edge report. Firefox shares the screen but cannot confirm which surface was chosen, so it always fails the strict check. Safari's screen-sharing support differs enough that strict mode is unsupported there too. All mobile browsers lack screen-sharing APIs entirely.
Relaxed screen recording drops the entire-monitor requirement: it accepts any surface (window, tab, full screen) as long as the exam page is visibly inside the shared stream, verified by a marker injected before the share picker opens. This extends support to Firefox desktop and, in principle, to Safari macOS — though Safari's sharing UX has not been verified on real hardware.
Single-monitor enforcement — Chrome and Edge only
Counting connected monitors requires the Window Management API, which only Chrome and Edge implement. On Firefox and Safari, enabling this setting blocks every candidate at the fullscreen step — even candidates with a single monitor — because the browser cannot respond to the count query. If you need monitor enforcement, candidates must use Chrome or Edge.
iPhone — no fullscreen lockdown
The iOS Fullscreen API is not available on iPhone (it is available on iPad). A non-relaxed fullscreen lockdown step therefore blocks iPhone candidates entirely — they reach a hard stop at the lockdown gate and cannot start the exam. Enabling relaxed lockdown removes the fullscreen requirement and instead tracks focus and visibility, which works on all devices including iPhone.
Safari and iOS — audio and video recording
Safari on macOS and all browsers on iOS record audio using AAC-in-MP4 and video using H.264-in-MP4 — WebM/VP8 is not available. TestInvite negotiates the appropriate container automatically, so candidates do not need to configure anything. Audio answers are converted to MP3 before upload regardless of the recording container. Both audio and video recording on Apple platforms are supported but have not been verified on real hardware end-to-end (record → upload → reviewer playback).
Screen recording — two methods
- Screenshot — captures periodic JPEG snapshots. Widest browser support across all screen-capable browsers.
- Screen capture — records continuous 60-second video clips. Requires
MediaRecordersupport in the browser. Modern desktop browsers handle this; Safari macOS records via MP4 but its sharing UX has not been verified.
Cameras and microphones on mobile
Mobile browsers support camera and microphone access via the same browser permission model as desktop. When more than one camera is available (for example, front and back cameras on a phone, or a laptop with an external webcam connected), a camera selector is shown after permission is granted so the candidate can pick the correct device.
All device support checks in TestInvite are performed by querying browser APIs directly — there is no browser-name detection. This means Chromium-based browsers (Opera, Brave, Vivaldi, Arc, and others) are automatically classified by what their engine actually supports, not by their name. Privacy-hardened browsers such as Brave may randomize or restrict media APIs; candidates on those browsers may need to lower shields if they encounter unexpected errors.