DeviceBenchFree multitouch and digitizer test
Touch screen test for every finger at once
Drag one finger or five across the field and each contact inks its own trail at the size the panel reports for it, with a live count beside the highest number of contacts the screen has managed to hold apart. Grid mode shades each of 96 cells the first time anything touches it, so a dead strip on the digitizer becomes a row that will not fill however often you wipe across it. Contacts the system takes back rather than you lifting them are counted on their own line, because palm rejection removing a finger on purpose is the single most common reason a working panel looks broken.
- 100% free
- No signup
- 96-cell grid
- Contact size and force
- Stylus and pen too
Drag across this panel with as many fingers as you can put down. A gap in a line your hand drew without stopping is a contact the panel lost.
Nothing on the glass. Hold a finger still here and the patch figure is the size the panel thinks your fingertip is.
- largest patch
- —
- peak force
- not measured
- kinds seen
- —
A contact ends here whichever way it ends, and only one of those ways is your finger leaving: the Canceled figure counts the ones the system took back. Nothing on this page can see the panel’s scan rate, its firmware version or the flex cable behind the glass, so a fault that comes and goes with temperature will pass a run that a warm phone fails.
How to test a touch screen
Three passes: one for continuity, one for the contact count, one for coverage.
Wipe one finger slowly over the whole panel
Keep the finger down and draw long sweeps from edge to edge, corner to corner, without lifting. The line that appears is every position the digitizer reported, so a break in it is a break in the reporting rather than in your hand. Pay attention to the shape of a break: a ragged stutter is usually a dirty or damp surface, while a break with a straight edge that repeats at the same coordinate is one electrode row that has stopped answering.
Put down every finger you can and read the two numbers side by side
Contacts now counts what is on the glass at this instant; Most at once holds the session peak. Compare that peak against Panel claims, which is what the driver advertises rather than anything it has demonstrated. Five is the normal ceiling on an iPhone or iPad, ten on most Android phones and Windows laptops, and a peak that stalls two or three below the claim while your fingers are clearly all down is the reading worth keeping.
Switch to Grid, fill the screen and hunt the cell that stays pale
Grid divides the field into 96 squares and shades each one the first time anything lands inside it, which turns a search into a checklist. Press Fill the screen first so the squares reach the glass near the bezel, where a digitizer usually fails first, and wipe in both directions three times. One square still pale after that, with its neighbors filled, is the coordinate to put in a repair ticket — Copy result writes it out with the contact counts as plain text.
Technical specifications
| What is measured | The hardware's own claim from navigator.maxTouchPoints beside the highest number of contacts this field has actually held apart at once — the pair is the reading, neither figure alone |
|---|---|
| Event source | Pointer Events, so finger, stylus and mouse take one code path; a pointerId stays with a contact from the moment it lands until it leaves |
| Contact patch | PointerEvent.width by height in CSS pixels, drawn at full size rather than as a radius; panels that do not measure contact area report exactly 1 by 1 |
| Force | PointerEvent.pressure from 0 to 1. A value that is neither 0, 0.5 nor 1 came off a sensor; a flat 0.50 on every contact is the placeholder the spec substitutes when there is none |
| Grid resolution | 96 cells, 12 across by 8 down, scaled to whatever size the field is; a cell shades on first contact and stays shaded until Clear |
| Gesture suppression | touch-action: none on the field, so a two-finger drag is delivered as pointer moves instead of being taken by the page scroller |
| Canceled contacts | Counted separately from lifted ones — palm rejection and a gesture the browser claims both arrive as pointercancel, which is why a healthy panel can appear to drop fingers |
| Data kept | None — coordinates are inked onto a canvas and discarded, and Clear or a reload leaves nothing behind |
Frequently asked questions
The panel claims 10 contacts but only 5 of my fingers show up. Which number is true?
Both, and they are answering different questions. navigator.maxTouchPoints is a number the touch driver declares at startup, not a result — Windows certification asks a touchscreen to handle at least five simultaneous contacts and most controllers then report ten whether or not the panel resolves ten cleanly under load. What the field measures is different: how many contacts the controller managed to keep separate while you actually held them there. A gap of one or two usually means two fingertips landed close enough for the controller to merge their blobs into a single contact.
My finger draws a broken line in one strip of the screen.
That strip is where the digitizer has stopped reading, and the shape tells you roughly why. Capacitive panels are a lattice of drive and sense lines, so losing one line kills a whole row or column — which appears as a straight band of the same width all the way across, not a blob. A band like that after a drop is usually the flex connector at the edge of the panel rather than the glass, which is why the fault often comes back when the phone warms up and the connector expands. A wandering, ragged gap that moves around is contamination on the surface instead.
Does a screen protector change the result?
It can, and thickness is the reason. A capacitive sensor works by measuring how your finger changes the charge held between two electrodes, and every millimeter you add between fingertip and lattice weakens that change — a thick tempered glass sheet, or any protector with an air bubble trapped under it, drops light touches first and edge touches next. Run the grid once with the protector on and once with it off before blaming the panel; if the pale cells move or disappear, the protector was the fault.
Why does resting my palm on the screen cancel the finger I was drawing with?
That is palm rejection, and it is a feature doing its job. The controller looks at the size of each contact patch — the same width and height figures this page prints — and a patch far larger than a fingertip is classified as a palm and suppressed, sometimes taking a nearby small contact with it because the two were probably one hand. The page counts these separately under Canceled, because the browser is told a contact was withdrawn rather than lifted, and a number that climbs only when your hand rests on the glass is rejection working rather than hardware failing.
Can I test an Apple Pencil, an S Pen or a drawing tablet here?
Yes, and the kind field will say pen rather than touch when you do. A stylus is the one input that fills the force column with real values instead of the placeholder, so if peak force reads 0.63 rather than sitting at exactly 0.50 you have proof the pressure sensor in the tip is reporting. Two stylus behaviors are outside this page: hovering above the glass without contact produces no contact to draw, and tilt and barrel rotation are carried on properties this field does not display.
Two fingers zoom the page instead of drawing. Is that the screen?
No, and it is worth knowing why the field escapes it. A browser claims a multi-finger gesture for panning and pinching before the page is offered it, unless the element under the fingers declares touch-action: none, which this field does — that is why a two-finger drag inks two trails here and scrolls everywhere else. What still sits above the page is the operating system: iOS accessibility zoom and Android's own system gestures are handled before the browser, so a three-finger double tap that magnifies the screen is not something any web page can intercept.
I am on a desktop with a mouse. Is there anything here for me?
The field still tracks the mouse as a single contact, so the trail and the grid work, but the count that matters has nothing to count and the panel claim reads zero. A mouse has its own failure modes that a touch panel does not, and they are measured elsewhere on this site: a cursor that stutters or skips is a sampling problem rather than a digitizer one.
About digitizers, contact counts and the strip that stops responding
A phone screen senses you through a lattice rather than a surface. Transparent conductors run in two directions under the glass, one set driving a charge and the other sensing it, and the controller scans the intersections looking for the places where a fingertip has bled some of that charge away. What comes back is not a point but a blob of affected intersections, which the controller has to resolve into a center, a width and a height before the operating system ever sees a touch. That resolution step is why two of your figures disagree: the width and height printed here are the blob the controller found, while the maximum contact count is a number the driver declared at startup, and nothing forces the second to survive contact with the first.
Because the sensing is a lattice, its failures are lines. One dead sense line takes a whole column out of service, so the classic result is a band of constant width where swipes stop being picked up while every other part of the screen works normally — distinct from an unresponsive corner, which is more often the flex ribbon at the panel edge working loose after a drop. Both are worth separating from things that only look like faults: sweat and water bridge neighboring intersections and make contacts merge or jump, a thick protector with an air gap swallows light taps, and the grid here will reproduce all of that faithfully, which is the point of running it twice under different conditions. If the mark you are chasing sits still while the image under it moves, it is on the glass rather than in it, and a plain white screen or black screen will show it far more clearly than any drawing will.
Most touch tests on the web get one thing wrong and it changes the answer. They listen for Touch Events, the older API, where identifiers are recycled the moment a finger lifts and a stylus is indistinguishable from a fingertip; this field uses Pointer Events, where an id belongs to one contact for its whole life and the kind field tells you what put it there. The second mistake is subtler: a page that does not set touch-action: none hands multi-finger gestures back to the browser’s scroller, then reports the resulting missing moves as a dead zone near the edges, which is a fault the test invented. Whatever the field finds, it stops at the glass — it cannot read the panel’s scan rate, its firmware or its calibration table. For the rest of what the device is willing to say about itself, including the touch-point claim in its raw form, see device info; for the pointing device on a laptop, where a dead strip under a trackpad produces the same broken line, the cursor test draws the equivalent trail. If taps register here but a game still misses them, the cps test counts taps on the same Pointer Events path, and the vibration and sensor test covers the parts of the phone that are not the screen.
Where the coordinates of your fingers go
Every number on this page is worked out by JavaScript running in the tab you are reading it in. Nothing you type, paste or open is uploaded, logged or kept, which is also why the tools carry on working after you disconnect from the network.
Each contact position is used once, to extend a line on a canvas and to shade a grid cell, and is then overwritten by the next one. No gesture is recorded, no path is stored and the drawing exists only as pixels in this tab, which is why Clear and a reload are equally final.