DeskTest.net
GitHub

Pen and Stylus Test Guide

A reference for the DeskTest.net Pen and Stylus Test. Covers how it reads pen pressure, tilt, twist, hover, the eraser end, and the barrel button, how to read the verdict, and what to do when pressure disappears or the browser sees your pen as a mouse.

Open the Pen and Stylus Test →

What does the Pen and Stylus Test check?

The tool drives the browser's PointerEvent API and filters to events whose pointerType is 'pen'. As you draw on the pad, it reads the analog values a pen exposes that a mouse or finger cannot: pressure (0 to 1), tiltX and tiltY, twist (barrel rotation), the hover state (a pen event with no button held), the eraser end (the buttons bitmask with bit 32 set, or button value 5), and the barrel button (buttons bit 2). No plugin, no extension, no upload. Works on Chrome, Edge, Firefox, and Safari. The three steps run in order:

  1. Pen input is supported. Confirms window.PointerEvent exists and that the pressure, tiltX, and twist properties are present on the event surface. This only proves the browser can report pen data - it cannot tell whether a physical pen is attached. If Pointer Events are missing (a very old browser or a restricted webview) the tool says so honestly and stops, rather than faking a result.
  2. Pen draws with varying pressure. A drawing pad captures your strokes. The line width tracks pressure, and a live readout shows the current pointer type, pressure, tilt, and twist, with chips that light up for hover, tilt, eraser, and the barrel button as they appear. The tool records the range of pressure seen while the tip is in contact and whether each optional feature was observed.
  3. Analog inputs report correctly. A summary derived from the drawing: whether pressure varied, and whether tilt, twist, hover, the eraser, and the barrel button were seen. Pressure is the only make-or-break input; tilt and twist are hardware-dependent and are never counted as failures.
Important: This test needs an active pen. Run it on the device with the pen - a Surface with a Surface Pen, an iPad with Apple Pencil, or a computer with a Wacom/Huion/XP-Pen tablet or pen-display connected. A mouse or a bare finger cannot report pressure or tilt, so the tool will correctly say "no pen detected" if that is all it sees.

When should I run this?

Reading the results

The Pressure bar and value update live as you press; the Pointer type, Tilt X / Y, and Twist fields mirror the current event. The chips - Pen seen, Hover, Tilt, Eraser, Barrel button - turn green once each is observed, so you can see at a glance what the pen has reported. Draw with the eraser end and hold the side button if you want those to register.

Each step row carries a status badge: Pending (gray), Running (yellow), Pass (green), Partial (yellow), or Fail (red). The drawing step passes when a pen is detected and pressure varies, reports Partial when a pen is seen but pressure is flat or the pen never touched down, and reports Partial (labeled "no pen detected") when only a mouse or finger reached the pad. The support step is the only hard Fail, and only when Pointer Events are unavailable. On a partial or fail the row expands with the diagnosis and a numbered checklist, and the verdict panel at the top names the most likely cause and a recommended next step.

Copy Diagnostic Report copies a plain-text report: browser user-agent, platform, whether the pen properties are exposed, the pointer types seen, the pressure sample count and range, its classification, and whether tilt, twist, hover, eraser, and the barrel button were observed. It also lists what the tool cannot determine. Paste it into a ticket.

Common failures and fixes

The tool produces a named diagnosis for every path. Each maps to a fix. In rough order of how often they occur:

non-pen-only: only a mouse or finger reached the pad

No pen pointer was ever seen; the readout showed mouse or touch instead. A pen or stylus is required - a mouse and a finger cannot report pressure or tilt.

  1. Use an active pen: a Surface Pen, Apple Pencil, or the pen that came with your Wacom, Huion, or XP-Pen tablet. A cheap passive capacitive stylus has no sensor and reports as touch.
  2. On a tablet or pen-display, confirm the pen is charged/paired and the vendor driver (Wacom, Huion, XP-Pen) is installed and its background service is running.
  3. On Windows, make sure Windows Ink is enabled in the tablet utility. With Windows Ink off, many drivers deliver the pen as plain mouse events and the browser never sees pointerType: pen.
  4. If the pen is on a touchscreen (Surface, iPad, pen-display) and still reports as touch, the digitizer may not distinguish the pen from a finger, or the pen is not the matching active stylus for that panel.

pen-seen-flat05: pen detected, but pressure is stuck at 0.5

The pen was recognized, but every pressure reading was a flat 0.5. Per the Pointer Events spec, 0.5 is exactly the value the browser reports for a device with no pressure information while a button is held - so pressure is not reaching the browser.

  1. Confirm the pen model actually supports pressure. A passive capacitive stylus never will.
  2. Install the vendor tablet driver and enable Windows Ink in its settings. Without the driver's pressure passthrough, the browser sees a flat 0.5.
  3. Restart the tablet driver/service after any OS feature update - updates frequently reset or break pressure.
  4. Test pressure in a native app or the OS pen settings. If it is flat there too, the problem is below the browser (driver or hardware); if it works natively but not here, update the browser.

pen-seen-flat: pen detected, but pressure did not vary

Pressure was reported at some non-0.5 value but stayed roughly constant. This is most often just how the strokes were drawn.

  1. Re-run and deliberately vary the pressure: start feather-light and build to a very firm press within a single stroke.
  2. If it still will not vary, check the nib is fully seated and not worn down, and confirm pressure varies in the OS pen-settings pressure test.
  3. Some drivers have a pressure curve set to a hard on/off or a fixed level - reset the curve to linear in the tablet utility.

pen-seen-none: pen hovered but never touched down

Hover was detected but the tip never made contact, so there were no pressure samples to judge.

  1. Re-run and actually draw on the pad - let the tip touch the surface and press lightly, then firmly.
  2. If the pen refuses to register contact even though it hovers, the nib switch may be stuck or worn; swap the nib.

Tilt or twist shows "not reported by this device"

This is not a failure. Tilt and twist are optional hardware features. Many perfectly good pens - including some Apple Pencil and entry-level tablet pens for twist specifically - have no tilt or barrel-rotation sensor, so the browser reports zero. The tool always shows these as informational, never as a fail. Only chase it if the pen's spec sheet says it supports tilt and your art app needs it; in that case verify the driver and app both have tilt enabled.

no-pointer-events: Pointer Events not supported

The browser does not expose the Pointer Events API, so no pen data can be read. This is the only hard fail.

  1. Update to a current version of Chrome, Edge, Firefox, or Safari.
  2. If you are inside a locked-down kiosk browser or an embedded webview, open the page in a full browser tab instead.

For IT admins

Pen behavior is governed at three layers: hardware (the digitizer and the pen's sensor), driver/OS (the vendor tablet driver, Windows Ink, and the pen settings), and per-app (the browser or art application). This test reads the per-app/browser view, but the failure pattern points at the layer to fix.

Windows Ink is the usual culprit. Wacom, Huion, and XP-Pen drivers have a "Use Windows Ink" toggle. With it off, the pen is delivered as mouse events - no pressure, no pointerType: pen - which reads here as non-pen-only or a flat 0.5. Standardize the driver config in your image and document the correct toggle state per application (some legacy art apps want it off, but browsers and modern apps want it on).

Feature updates break pressure. Windows feature updates routinely reset or disable the tablet service, leaving a pen that moves the cursor but reports flat 0.5 pressure. Bake the vendor driver into your image and re-validate pen pressure after each major update on the affected models.

Passive vs active styluses. A capacitive "dumb" stylus registers as touch and has no pressure or tilt - do not treat that as a hardware fault. Record the correct active pen model per device so a genuine pen fault is distinguishable from someone using the wrong stylus.

What this tool does not measure. It confirms that pressure varies and that tilt/twist/eraser/barrel reach the browser. It does not measure pressure-level depth (2048 vs 8192 levels), pressure-curve accuracy, or cursor parallax/calibration - how closely the drawn point tracks the tip. Those need the vendor diagnostic utility. Calibration drift on a pen-display is fixed in the OS or vendor calibration applet.

Kiosk shells and iframes. A locked-down browser or an embedding iframe can reinterpret pen input as emulated mouse events. The report notes whether the page is in an iframe. If a kiosk misbehaves, test the same URL in a full browser tab on the same device to separate a shell problem from a hardware one.

Behind the scenes

The tool uses Pointer Events because they unify mouse, pen, and touch and, for a pen, expose the analog channels directly on the event: pressure, tiltX/tiltY, twist, and the buttons bitmask. It filters strictly to pointerType === 'pen' for all analysis; non-pen input still gets a faint line for feedback but is never counted, and the readout names the actual pointer type so a mouse cannot masquerade as a passing pen.

The pad is a <canvas> with touch-action: none set in CSS, so a drag paints instead of scrolling or triggering pinch-zoom. On pointerdown the canvas calls setPointerCapture() so it reliably receives the matching pointerup. Each stroke's width is base + pressure x scale; the eraser end draws with destination-out compositing so it genuinely erases. The barrel button's contextmenu is suppressed on the canvas so a side-button press does not pop a menu mid-test.

Pressure is classified from the samples taken while the tip is in contact: a range of at least 0.06 between the lowest and highest reading counts as "varies" (a pass); samples all within 0.03 of 0.5 are flagged as "no pressure sensing"; a narrow band elsewhere is "did not vary". Tilt and twist are marked "reported" only if a non-zero value ever appeared, and "not reported by this device" otherwise - deliberately, so absent hardware is never scored as a fault.

Nothing leaves the browser tab. No strokes, pressure curves, or coordinates are logged to a server, no telemetry beacon is fired, no analytics. The report is built on Copy from in-memory state, and the page discards everything on reload. Open DevTools, Network tab, and confirm: no outbound requests while the test runs.