Hardware
TesterProximity Sensor Tester
Test a proximity sensor in your browser over HTTPS, log near/far transitions and distance, and export CSV/JSON. Note: most browsers and iOS lack a web proximity API.
Have feedback? Report bugs, suggest features, or share your thoughts — we read them allAbout Proximity Sensor Tester
Proximity Sensor Tester visualizes the near/far response from your device's infrared proximity sensor and records the session for repair and QA evidence. Watch the animated indicator change color as objects move closer or farther, count near/far transitions to spot chatter, track min/max/avg distance, and export the timestamped log as CSV or JSON. Note: the proximity Web API requires a secure (HTTPS) connection and is only available behind a flag in some Chromium browsers — desktop browsers and iOS generally cannot access it.
- Open this page over HTTPS — a proximity sensor is unavailable on insecure (http) connections, and most desktop browsers and iOS cannot expose it at all.
- Press Start testing and allow proximity access if your browser prompts for permission.
- Hold the device flat and wave your hand toward the top bezel where the sensor is usually located.
- Watch the Near/Far indicator and distance values, and check the transition counter for chatter (rapid flicker means a misaligned IR pinhole or grease).
- Move away to confirm the indicator returns to Far, then export the session as CSV or JSON to attach to a repair ticket, or hit Reset for a fresh session.
Frequently Asked Questions
A phone proximity sensor measures the distance — or more precisely, the presence — of an object within a few centimeters of the screen. It works by emitting infrared light (typically at 850 or 940 nanometers, invisible to the human eye) from an IR LED and measuring how much of that light bounces back into a small IR photodiode. The reported value can be either a raw reflectance count, a calibrated distance in centimeters, or a simple near/far binary flag depending on the chip and the operating system. Phones use it to turn off the screen during calls (avoiding cheek taps), automate flip-to-mute, and detect pocket / face-down scenarios. The Web Proximity API exposes value in centimeters along with min/max distance.
Because the browser genuinely has no proximity API to call. The legacy DeviceProximityEvent/UserProximityEvent were removed from virtually every browser years ago, and the modern Generic Sensor ProximitySensor ships only in Chromium and is usually hidden behind the experimental Generic Sensor Extra flag. iOS Safari exposes no proximity interface to web pages at all — Apple keeps it native-only (UIDevice.proximityState). Desktop machines also typically have no physical proximity sensor. So a 'not supported' or 'no data received' message is the honest, expected result on most setups, not a bug in the tool. The realistic place to see live readings is an Android phone running a Chromium browser with the proper flag enabled, served over HTTPS.
Everything runs locally in your browser. The tool reads the proximity values directly from the Web Sensor API on your device, computes the near/far state, transition count, and min/max/avg distance entirely in JavaScript on the page, and renders them live. Nothing is uploaded — there is no server call with your sensor readings, no account, and no tracking of the values. When you export a session, the CSV or JSON file is generated in-memory and downloaded straight to your device; it is never transmitted to us. If you want to share a captured session with a colleague or attach it to a repair ticket, you do that yourself with the downloaded file.
The big circle is the live state: green NEAR means an object is within range, blue FAR means the path is clear, and grey means no reading yet. 'Current distance' is the latest centimeter value (when your hardware reports continuous distance), and 'Sensor range' is the maximum the chip can measure. The session panel adds objective evidence: 'Readings' is how many samples have arrived (a frozen sensor stops incrementing), 'Near/Far transitions' counts how many times the state flipped — a clean cover-and-uncover should add one or two, while a rapidly climbing count signals chatter from a misaligned IR pinhole or grease, and Min/Max/Avg distance document the effective range. Some sensors report only near/far with no distance; in that case a derived state is computed from your chosen threshold and clearly flagged as derived rather than reported.
Proximity sensors fail in subtle ways: a thin film of grease, a misaligned screen protector, or a recalibration bug can leave the screen pitch-black during calls or refusing to turn on. Testing confirms the sensor sees objects only when they are close, ignores ambient light correctly, and produces a clean near/far transition rather than chattering. Repairers often need to verify proximity after replacing a screen because the IR pinhole must align perfectly with the under-display gap. App developers also test edge cases — dark vs light objects reflect IR very differently, and some matte black surfaces register as far away even when touching the screen.
On Android, Sensor.TYPE_PROXIMITY returns centimeters, but many phones only report two values: 0 cm (near, screen blocked) and the sensor's maximum range (typically 5–8 cm = far). The W3C ProximitySensor API exposes a continuous value in centimeters along with min and max range constants. On iOS, the proximity state is exposed only as a boolean (true/false) through UIDevice.proximityState — there is no continuous distance reading available to web apps. Brightness changes can also be reported as lux from a co-located ambient light sensor, but that is a separate API. Always check sensor.max to know the effective range — anything beyond returns the max.
Proximity sensors rely on optical reflection of IR light, so any object that absorbs IR — black fabric, dark hair, matte phone cases — bounces back very little signal and registers as far away. Light or shiny objects reflect strongly and trigger the near state easily. This is a fundamental limitation of IR-based sensing. Some premium phones use a time-of-flight (ToF) chip that measures the actual round-trip flight time of the IR pulse, giving accurate distance regardless of surface color. ToF chips are also less affected by ambient sunlight. If your sensor seems to ignore your dark hair during calls, that is normal behavior for a reflectance-based design — try resting the phone differently on your ear.
Bright sunlight contains a large amount of IR energy in the same band as the sensor's LED, which would saturate the photodiode and confuse it. Modern proximity chips solve this with synchronous detection: the LED pulses at a known frequency (often 100 Hz) and the photodiode demodulates only signal energy at that frequency, rejecting steady ambient IR. Some chips also use a narrow optical bandpass filter centered at 940 nm to block visible and near-IR sunlight. If you take your phone outside on a sunny day and the proximity sensor stops working, the chip has likely run out of dynamic range. Reset by covering the sensor briefly, then uncovering — most chips auto-calibrate the ambient baseline at that point.
Most consumer proximity sensors emit at 940 nm (some at 850 nm). The 940 nm wavelength has two important advantages. First, it sits in a narrow dip in the solar spectrum where atmospheric water vapor absorbs sunlight, reducing background interference outdoors. Second, it is far from visible light (380–700 nm) so users do not see a red glow on the phone even though the LED is constantly pulsing. The trade-off is that silicon photodiodes have slightly lower sensitivity at 940 nm than at 850 nm, requiring more LED power. ToF chips like the STM VL53L0 use 940 nm pulsed at sub-nanosecond intervals. The IR LED draws only microamps so battery impact is negligible.
Two APIs are relevant. The legacy DeviceProximityEvent and UserProximityEvent were standardized by W3C in 2012 but have been removed from most browsers due to privacy concerns (they can identify a user by ear shape and head distance). The newer Generic Sensor API exposes ProximitySensor, but support is limited — currently only Chromium with the Generic Sensor flag enabled. On iOS, no proximity API is exposed to the web; native apps use UIDevice.proximityMonitoringEnabled. This tool uses feature detection: it tries Generic Sensor first, falls back to DeviceProximityEvent if available, and otherwise shows a graceful 'not supported' message. Permissions API also gates access on Chromium.
Consumer proximity chips (AMS TMD2725, STM VL6180X, Vishay VCNL4040) are characterized by detection range (typically 5–100 mm for reflectance, up to 200 cm for ToF), wavelength (850 or 940 nm), ambient-light rejection (specified as μW/cm² of co-incident IR), response time (50–200 ms), and angular field of view (15–30°). IEC 60825 defines the eye-safety classification for the IR LED — almost all phone sensors are Class 1 (eye-safe under all conditions). ISO 13628 covers proximity sensor testing in industrial settings. For ToF chips, the ANSI Z136.1 laser safety standard sets exposure limits; consumer ToF emitters operate well below these thresholds. The chip's IR LED also draws minimal current (~10 mA pulsed) so battery impact is negligible.
SENSORS13
WUTOOLS