Browser capability detection for a web app

A web app can work on your development computer and still fail for a customer using a different browser, device, or privacy setting. Features such as camera access, video playback, and local file handling depend on more than the browser name.

Before deployment, check the browser you are testing, then verify the features your app actually needs. TooLab's Browser Info reports browser version and engine, permissions, privacy settings, codecs, and supported features. Use it as a starting point, then test your app on its real deployment address.

Check browser capabilities before launch

1. Open Browser Info in the browser and device you want to check. If you are testing a phone, open the page in its browser rather than relying on a desktop report.
2. Review the browser version and engine. The engine is the part of the browser that processes web pages. Record the results for each browser and device you plan to support.
3. Look through the supported features and compare them with the requirements of your app. Check the specific capabilities your code uses, rather than expecting a single overall compatibility score.
4. Review the reported permissions and privacy information. If your app needs camera, microphone, location, or other access, check whether the browser can request it and whether the current permission state allows it.
5. Check the codecs relevant to your media. A codec is a format used to encode or decode audio and video. Test the actual files or streams your app will play, since a browser's general support does not guarantee every file will work.
6. Repeat the check on your staging or production address and use the app's main workflow. A browser report cannot confirm that your server, page security, embedded frames, or app code are configured correctly.

Keep a short record of the browser, version, device, and any features that failed. That makes it easier to reproduce a report from a tester and to decide whether to fix the app, change its requirements, or provide another route.

What the results mean

A feature is reported as supported

This is a useful indication that the browser exposes that capability, but it is not proof that your app will use it successfully. The feature may depend on a secure connection, a user gesture, permission, or a particular device. Test the full action on your deployed site, not just the browser report.

A feature is missing or unavailable

The browser or its current environment may not provide the feature. It could also be disabled by a privacy setting, a managed device policy, or a restricted context such as an embedded page. Check the same feature on a second supported browser and on the app's actual origin before treating this as a device defect.

A permission is blocked or not yet granted

Capability and permission are different. A browser may support camera access while the user or system has denied it. Your app should explain why access is needed, handle a denied request, and offer a way to continue without that feature when possible.

A codec is listed, but playback fails

Support can vary with the exact codec, container, profile, and device. A container is the file wrapper, such as MP4, while the codec describes how its media is encoded. Try a representative sample from your app and provide a fallback format if your audience needs one.

How to handle capability gaps

1. Detect the feature your code needs. Prefer checking for a specific API or behavior, such as "mediaDevices" in navigator, rather than assuming support from a browser name. A browser version check can become outdated and may exclude a browser that works.
2. Provide a fallback. If a feature is unavailable, show a clear message and offer another path. For example, a media page might provide a downloadable file, while a camera-based workflow might allow users to upload an existing image.
3. Ask for permission only when needed. Camera and microphone access require a user permission prompt. Explain the reason before the request, trigger it from a user action, and handle a denial without leaving the page stuck.
4. Check the browser and system permissions. In Windows 11, open Settings › Privacy & security › Camera or Settings › Privacy & security › Microphone, and allow access for the browser as appropriate. On macOS, open System Settings › Privacy & Security › Camera or System Settings › Privacy & Security › Microphone.
5. Check phone permissions and site settings. On Android, open Settings › Apps › your browser › Permissions, then check the relevant permission. On iPhone, check Settings › Privacy & Security › Camera or Settings › Privacy & Security › Microphone, and review the website permission in the browser if access is still blocked. Menu names can vary by operating system version.
6. Update and retest. If an expected feature is missing, install available browser and operating system updates, then test again. On managed work or school devices, an administrator may control which features are allowed.

Test in the context you will deploy

Browser capability checks are clues, not a substitute for testing the app. A feature may work on a secure top-level page but fail on an insecure address or inside an embedded frame. Permissions can also be restricted by the frame or by the browser's site settings.

Build a small test plan around the actions users need to complete. Include at least one older supported browser, a current desktop browser, and the mobile browsers your audience uses. Test with permissions allowed and denied, and include a realistic video, image, or file if the app depends on one.

If a browser report contains a surprising device or privacy detail, treat it as a hint rather than a promise about what every user will see. Browser settings and privacy protections can change which information is available.