Touch Screen Test

What is this tool?

The Touch Screen Test turns your screen into a canvas that records every pointer event the browser reports. Each finger gets its own colour and its own trail, and the panel beside the canvas shows how many points are down, how long each has been held, how far it has travelled and how fast.

It listens to Pointer Events rather than legacy touch events, which is why it works the same for a finger, an active stylus and a mouse, and why the log tags every entry with the pointer type. All six modes share that one engine — they differ only in what they ask you to touch.

The point of the modes is coverage. Randomly poking a screen proves very little; sweeping a 5×5 grid until all 25 cells register, or clearing all 14 edge and corner segments, proves that no region of the digitiser is dead.

How to use it

1. Pick a modeQuick Test is free drawing. Accuracy places nine targets. Multi-Touch counts simultaneous fingers. Grid Test divides the canvas into 25 cells. Tracking follows a continuous drag. Edge Test isolates the four corners and the ten edge segments around them.
2. Draw across the whole canvas firstIn Quick Test, drag one finger slowly over every part of the area in overlapping passes. A trail that breaks, jumps or stops while your finger is still down is the signature of a digitiser problem, and it is much easier to see in a slow sweep than a fast scribble.
3. Run the grid to prove coverageGrid Test marks a cell as tested the moment a touch lands inside it, and shows tested count and coverage percentage. Work methodically row by row until it reads 25 of 25; any cell you cannot turn on with a deliberate press is a dead zone.
4. Run the edge test for the hard partsEdges and corners fail first, because that is where digitiser wiring, adhesive and curved glass meet. The edge mode splits the border into 4 corners, 3 top, 3 bottom, 2 left and 2 right segments — 14 in total — so you can confirm each individually.
5. Count your multi-touch limitIn Multi-Touch mode place fingers down one at a time and watch the maximum simultaneous figure climb. Add fingers until it stops rising: that number is your panel's practical limit, and it also confirms the panel is not dropping points when several are down.
6. Check accuracy and then exportAccuracy mode gives nine targets with shrinking radii, from 34 px in the top-left down to 18 px in the bottom-right, and records how far each hit landed from the centre. When you are done, Export writes the whole pointer event log to CSV for a repair ticket.

What the results mean

Max simultaneous touches

The highest number of pointers the engine saw down at once. Modern phones typically report five or ten; a panel that refuses to go past two while you have four fingers down is either limited by design or losing points.

Touch response

The gap between the timestamp the browser stamped on the event and the moment the page's code ran, clamped to a 1–250 ms window, and labelled Excellent under 30 ms, Good to 60 ms, Average to 100 ms and Slow beyond that. It is a browser-to-script delivery figure, not your screen's hardware touch latency.

Grid coverage

Tested cells out of 25 and the percentage. Anything short of 100% after a deliberate sweep localises the fault — note which cells stayed dark, because that map is the useful part of a service report.

Edge coverage

Tested segments out of 14. Corners failing while the middle of the screen works is the classic pattern after a drop or a badly fitted screen protector.

Accuracy hits and average distance

How many of the nine targets you hit, the misses, the hit percentage and the mean distance in pixels from target centre. A consistent offset in one direction across every target suggests a calibration or digitiser alignment issue rather than clumsy aim.

Pressure

Shown only when the browser reports a real value. The engine deliberately ignores an exact 0.5 from a finger, because that is the synthetic default browsers substitute when there is no pressure sensor — so Not Supported here means your hardware or browser is not exposing pressure, not that the test failed.

What it can detect

• Dead zones — regions where a deliberate press produces no pointer event at all, isolated by the grid and edge modes
• Dropped or jumping trails during a continuous drag, which indicate an intermittent digitiser rather than a fully dead area
• Ghost touches — pointer events appearing with nothing on the screen, visible as trails you did not draw
• A multi-touch ceiling lower than the panel should support, or points being dropped when several fingers are down
• Edge and corner insensitivity, often caused by a thick case or a screen protector overlapping the active area
• Systematic accuracy offset, where every hit lands the same distance in the same direction from target centre
• Whether the browser exposes stylus pressure and pointer type at all, which tells you if a pen is being seen as a pen

Limits worth knowing

A browser can only report what the platform gives it. These are the honest boundaries of this page, so a result is never read as more than it is.

• The response figure is not hardware touch latency. It measures the delay between the browser's event timestamp and this page's JavaScript running, so it excludes the panel's own scan time and the compositor, and includes browser and page overhead. The page keeps its own “Touchscreen Test Limitations” section for the same reason.
• It cannot test area the browser cannot reach. Anything outside the canvas — system gesture zones, notification shade regions, on-screen navigation bars — is off limits, so a full-panel verdict needs the manufacturer's service tool.
• Pressure and stylus tilt are only reported if the browser chooses to expose them. Most fingers on most devices report no usable pressure, and the engine treats a flat 0.5 as no data rather than pretending it is a reading.
• It cannot distinguish a hardware fault from a software one. A dead cell can be a broken digitiser, a loose connector, a case pressing the edge, or a driver problem — the test tells you where, not why.
• The canvas sets touch-action: none so that scrolling and pinch-zoom do not steal your gestures. That is deliberate, and it is why the page does not scroll while you are drawing inside the test area.
• Nothing you touch is uploaded. Trails, statistics and the event log stay in the page, and the CSV export is generated locally in your browser.

Tips

• Take the case off and lift any screen protector edge before blaming the panel. Cases and protectors are the single most common cause of edge and corner insensitivity, and the edge mode makes the difference obvious in seconds.
• Sweep slowly for dead zones and quickly for tracking. A slow pass finds regions that never respond; a fast drag exposes trails that stutter or lag, which is a different fault with a different fix.
• Export the log and note which grid cells stayed untested before contacting support. A reproducible cell map is far more persuasive than “the screen sometimes ignores me”.

Troubleshooting

Related documentation

• MobileMobile Device TestA thirteen-item capability scan of your phone — touch, sensors, screen, camera, microphone, audio, network, battery, haptics and wake lock — in one page.
• MobileScreen Orientation TestLive portrait and landscape state, rotation angle, screen versus viewport dimensions, a two-step rotation test and the orientation lock API.
• DisplayDead Pixel TestFull-screen solid colours for finding dead, stuck and hot pixels by eye.
• DisplayDisplay FPS TestMeasure the frame rate your browser is actually delivering, with 1% lows and jitter.
• MobileGyroscope TestLive X, Y and Z rotation rate in rad/s and deg/s, a scrolling activity graph, a guided three-axis test and a five-second zero-motion check.