Open a flashlight website and it looks simple: the screen goes white, maybe there are some controls. But what’s actually happening involves display hardware, browser APIs, and some choices about how modern web pages manage screen behavior. Understanding the mechanics explains why some implementations work better than others.

LCD vs OLED: Fundamentally Different Backlight Behavior

The two dominant screen technologies in phones and tablets work very differently, and that difference matters for how a white screen produces light.

LCD Screens

An LCD (Liquid Crystal Display) screen uses a constant backlight — typically an array of LEDs behind the panel. The liquid crystal layer sits in front of that backlight and acts as a set of pixel-level shutters. Open shutter = light passes through. Closed shutter = light is blocked.

Here’s the key implication: in an LCD display, the backlight is always on at full intensity (or close to it). Dark areas of the screen aren’t actually turning off light — they’re blocking it. A pure black image on an LCD panel is just the backlight’s light being blocked by closed crystals. Some of it still leaks through, which is why LCD screens have imperfect black levels.

A pure white image on an LCD does the opposite: every pixel shutter is fully open. The full backlight intensity passes through. This is why a white screen on an LCD is genuinely at maximum output — you’re not adding light, you’re removing all the things that were blocking it.

OLED Screens

An OLED (Organic Light-Emitting Diode) screen has no backlight. Each pixel emits its own light by passing current through an organic compound that glows. Black pixels are truly off — no power, no light. This is why OLED screens have perfect blacks and exceptional contrast ratios.

The implication for a white screen flashlight: a pure white image on an OLED lights up every single pixel simultaneously. Every pixel is drawing current and emitting light. This makes a full-white OLED screen one of the highest power-draw states the display can be in — the inverse of the LCD case, where white is just “not blocking the backlight.”

For OLED phones especially, the battery cost of using the screen as a flashlight is meaningfully higher than for LCD devices at equivalent brightness settings. This is worth knowing if you’re managing battery during an outage.

Why Maximum Brightness Matters

A smartphone screen’s brightness is measured in nits (candelas per square meter). Modern flagship phones can reach 1000–2000 nits at peak brightness. Mid-range devices typically land in the 400–700 nit range.

For a screen to function as a useful light source, you want that brightness as high as possible. But browsers don’t automatically get to control system brightness. That’s where APIs come in.

The Screen Brightness API

There is a proposed Screen Brightness API in the W3C specification pipeline that would allow web apps to request a specific brightness level. As of 2026, it has partial support in some environments but is not universally available. Most implementations in well-built web flashlight apps include a JavaScript call to request maximum brightness where the API is available, falling back to relying on the user’s existing brightness setting where it isn’t.

This flashlight tool requests maximum screen brightness on devices and browsers that support it, so you don’t have to manually max out the slider before using it.

Wake Lock: Keeping the Screen On

The most practically important piece of browser tech in a flashlight app isn’t brightness — it’s the Wake Lock API.

By default, a phone screen will dim and then turn off after a period of inactivity. For a normal app, that’s fine. For a flashlight, it’s a significant problem: you set the screen white, put the phone down to illuminate a space, and 30 seconds later the screen goes dark.

The Wake Lock API, available in modern browsers (Chrome, Edge, Safari with some caveats), lets a web page request that the screen not turn off. The API call looks something like this:

const wakeLock = await navigator.wakeLock.request('screen');

When a site acquires a screen Wake Lock, the operating system’s screen timeout is suspended. The screen stays on as long as the lock is held. The app needs to manage this responsibly — releasing the lock when the user navigates away or closes the tab.

Wake Lock can be interrupted. If the user switches apps, minimizes the browser, or the system decides to override it for battery reasons, the lock may be released. A properly written flashlight app listens for this and reacquires the lock if it’s dropped unexpectedly.

The Role of CSS and Rendering

The visual output of a screen flashlight starts with something simple: a CSS rule that sets the background color to white.

body {
  background-color: #ffffff;
  margin: 0;
  padding: 0;
}

A pure white #ffffff tells the display to render every pixel at maximum red, green, and blue output simultaneously. The browser converts this CSS instruction into pixel-level instructions that the GPU renders to the display hardware. On an LCD, that means opening all crystal shutters. On OLED, it means powering every pixel at full intensity.

For a colored flashlight, the same logic applies but with a specific color value. A red screen (#ff0000) tells the display to drive the red subpixel of every pixel at maximum intensity while keeping green and blue subpixels off. This is how colored light modes work — they’re not filtering a white light, they’re instructing the display hardware to emit only certain wavelengths.

Full-Screen Layout

Alongside color and brightness, a flashlight needs to fill the entire screen — no browser chrome, no status bar, no UI gaps. This involves a combination of CSS viewport units and, where possible, the Fullscreen API:

document.documentElement.requestFullscreen();

Fullscreen mode removes the browser’s address bar and navigation controls, maximizing the lit area. Some mobile browsers handle this differently — iOS Safari, for instance, has limitations on programmatic fullscreen that affect when it can be triggered. Responsive implementations account for this and present a large lit area even outside true fullscreen.

Putting It Together

A well-implemented browser flashlight is doing several things simultaneously: rendering a full-viewport CSS color to maximize light output, holding a Wake Lock to prevent screen sleep, requesting maximum brightness where the API permits, and managing the fullscreen state to eliminate gaps.

For comparison, the LED flash on a smartphone is controlled through an entirely different path — native hardware access that no web browser can replicate. The LED torch is genuinely brighter and more directional. But the screen, as a diffuse light source with color control and software flexibility, has capabilities the LED doesn’t — and those capabilities open up a wider range of practical uses than most people realize.

The browser is not a natural home for a flashlight. But the combination of Wake Lock, brightness requests, CSS color, and fullscreen layout makes it a functional one — and the gap between a well-built web flashlight and a native app is smaller than most people would expect.