About this monitor test

A small, dependency-free tool for one job: showing correct, full-screen test patterns so your own eyes can check a display for dead pixels, stuck pixels, backlight bleed and colour uniformity. No account, no upload, nothing you do here is recorded.

Why it exists

Checking a screen for dead or stuck pixels does not need a native app — it needs a handful of correct, uninterrupted flat colours filling the whole display, and a way to step through them without hunting for a "next" button while squinting at a corner of the panel. That is genuinely all this tool does: it hands the browser a single solid colour, a gradient or a fine pattern, tries to take over the whole screen with the Fullscreen API, and gets out of the way.

The stuck-pixel flasher exists for the same reason people already reach for this kind of tool in the first place — a stuck subpixel is sometimes recoverable by cycling it rapidly through different colours, and that is fiddly to set up by hand but trivial for a web page to automate, provided it is gated behind a clear warning.

How the patterns work

  • Solid colours are applied as a plain CSS background colour on a fixed, full-viewport element — no filters, no blending, no colour management beyond whatever your operating system and monitor already apply to any web page.
  • The gradient is a single linear CSS gradient from black to white, left to right, to make brightness banding or an uneven patch visible against a smooth ramp.
  • The checkerboard is a repeating conic gradient sized to alternate every device pixel, which is the standard CSS technique for a crisp one-pixel checkerboard without an image file. At non-100% zoom or non-native display scaling this pattern is the first thing to visibly blur, which is exactly why it doubles as a scaling/sharpness check.
  • Navigation inside the fullscreen view — arrow keys, space, click, and Escape — is wired with ordinary keyboard and click event listeners; nothing depends on a gamepad or any input beyond a keyboard and mouse/touch.

The Fullscreen API, and what happens when it isn't available

The test view calls the standard Element.requestFullscreen() (with a fallback to the older webkitRequestFullscreen for Safari) so the pattern fills the entire display and the browser's own chrome gets out of the way. That call is guarded: if neither method exists, or the browser refuses the request, nothing throws — the test view is a fixed-position element already covering the full viewport underneath, so the patterns still work, just with the browser's address bar or tab strip potentially still visible around the edges.

Leaving the test is handled the same defensive way. Pressing Escape, clicking the on-screen exit button, or the browser's own fullscreen-exit gesture (F11, swiping down on some touch devices) are all listened for, and a fullscreenchange listener catches the case where the browser exits fullscreen on its own — for example if you switch apps — so the test view's cursor-hiding and keyboard handling always get torn down rather than left running invisibly.

The stuck-pixel flasher, and why it's gated the way it is

Rapid, high-contrast flashing is a known trigger for seizures in people with photosensitive epilepsy, and can cause discomfort in people without a diagnosis. Because of that, the flasher:

  • Never starts automatically — it requires an explicit checkbox acknowledging the risk before the start button is even enabled.
  • Cycles at a fixed, moderate rate rather than as fast as possible, which keeps the general flash rate close to commonly cited safety guidance while still giving the technique a real chance to work.
  • Can be stopped instantly — Escape, a click anywhere on the flashing area, or the exit control all stop it immediately, with no confirmation step in the way.
  • Still requires the same explicit opt-in even if your system requests reduced motion — the tool surfaces that as an extra note rather than silently blocking the feature you came here to use.

Scope and honest limits

This tool takes over the browser viewport and paints correct colours into it. It has no way to see anything the operating system compositor, colour management pipeline, or the monitor's own on-screen processing does to that image afterwards, and no way to measure refresh rate, response time or HDR brightness. Results depend on your browser zoom being at 100% and your display running at its native resolution — anything else resamples the image before it reaches the panel. The flasher is the standard attempt at recovering a stuck subpixel, not a guaranteed fix, and does nothing for a genuinely dead pixel.

How it's built

  • Static HTML, one stylesheet, two small scripts. No framework, no build step, no bundler.
  • Nothing is uploaded. There is no server call anywhere in the tool; every pattern and the flasher run entirely on your device.
  • System font stack, dark mode by default, with a light theme via prefers-color-scheme.