The 4% rule: picking app background colors that survive cheap phone screens

작성자

카테고리:

← 피드로
DEV Community · Daksh Gargas · 2026-08-03 개발(SW)
Cover image for The 4% rule: picking app background colors that survive cheap phone screens

Daksh Gargas

Every design team eventually ships a beautiful off-white, off-blue, or off-anything background… and then opens the app on a $120 phone and watches it turn dirty gray. Same hex, same build. This post explains why, and gives you a small formula to convert any tint you’ve chosen into one that survives budget panels.

Why subtle tints die on cheap screens

Four panel-level failure modes, all common in the budget tier:

1. Weak gamut coverage. Entry-level LCDs cover only a fraction of sRGB — independent panel measurements routinely land in the 55–70% range, with large per-color error. A low-chroma tint simply doesn’t have the budget to survive that compression.

2. Cold white points. sRGB assumes a D65 white (6500K). Budget modules commonly ship visibly cooler — high-6000s to 9000K+ — because blue-ish whites look “brighter” in a store. That blue cast is spread across the entire grayscale, and its magnitude is comparable to a subtle warm tint. Net result: the panel can cancel your background color outright.

3. Stretched gamuts on budget AMOLED. The opposite failure: “vivid” default modes stretch sRGB content across the panel’s wider native gamut. Your quiet tint renders at roughly double saturation and suddenly has an opinion.

4. Banding. Many cheap panels are 6-bit + FRC. Soft near-white gradients develop visible steps, which makes barely-different surface colors look like rendering bugs.

The 4% rule

You don’t need a colorimeter to know if you’re at risk. Use channel spread — the distance between your highest and lowest RGB channel — as a chroma proxy:

spread = max(R, G, B) − min(R, G, B)

If spread is under ~10 of 255 (≈4%), your tint is inside a cheap panel’s error bar. It may render as intended, as gray, or as tinted the other direction — you don’t get a vote. (Quick check on any hex: two outer pairs of digits within ~0x0A of each other = you’re in the danger zone.)

Why 4%? Because that’s the same order of magnitude as the grayscale tint produced by a few-hundred-kelvin white-point error — the most common budget-panel defect. Your color and the panel’s error are the same size, so the panel wins half the time.

Converting your color: the budget-tier formula

Don’t pick a different color for cheap devices — that forks your brand. Derive the same hue at higher chroma:

  1. Take your canvas color. Find maxC (highest channel), and each channel’s distance from it: d = maxC − channel.
  2. Pick a spread multiplier k — 2 if your spread is ≤4%, 1.2–1.5 if you’re already near 5%.
  3. Drop the ceiling a touch so cards can sit above the canvas in pure white: maxNew = maxC − 4.
  4. Each new channel = maxNew − d × k.

Worked example — say your designer chose a cool “paper blue” #F2F5FA:

  • Channels 242 / 245 / 250 → spread 8 (3.1%): danger zone.
  • k = 2, maxNew = 246.
  • R = 246 − (8×2) = 230 → E6 · G = 246 − (5×2) = 236 → EC · B = 246 → F6.
  • Budget variant: #E6ECF6 — spread 16 (6.3%), same hue, twice the presence, and pure #FFFFFF cards now sit a clear step above it.

The same math works on warm creams, mint-greens, blush-pinks — hue never changes, only its insistence. If you prefer perceptual tooling: convert to OKLCH, multiply C by ~2, subtract ~0.01 from L, keep H — same result with cleaner math. (Avoid HSL for this: its S value is wildly misleading near white.) Either way, your background lightness barely moves, so text contrast ratios are essentially unchanged — but re-run your AA checks anyway.

Ship it as tiers, not themes

  • Tier 1 — color-managed panels (iPhones, flagship Androids): your original tint, near-white cards.
  • Tier 2 — budget panels: the converted tint, pure-white cards, hairlines nudged one step darker.

Everything else — ink, accent, type — stays identical. Users never see “a different theme”; they see the same brand, legible. Platform low-RAM/entry-device flags are a good-enough proxy for panel class to pick a default, and a small Paper tone: Auto · Soft · Rich setting covers the misfires (and the users who simply prefer one).

Test on glass, not in Figma

Emulators show you your monitor’s opinion. On the real device, at full brightness and ~40%:

  1. Does the canvas read as a color — or as a white that needs cleaning?
  2. Can you see where a card ends without tilting the phone?
  3. Is a canvas→white gradient smooth, no steps?
  4. Is your content (photos especially) still the warmest, richest thing on screen?

Four yeses on your cheapest test device and you’re done.

Takeaways

  • Subtle off-whites are a flagship luxury; under ~4% channel spread you’re inside the error bar of a cheap panel.
  • Never fork the color — scale its chroma: maxNew − d × k, hue untouched.
  • Pure-white cards above a slightly stronger canvas beat shadow-only hierarchy on washed panels.
  • Tier by device class with a user override; test with eyes on real glass.

Sources & further reading

Panel measurement & gamut coverage

White points

Bit depth & banding

Color math & platform APIs

Most measurement sources above are monitor/laptop reviews — the panel physics is identical, and phone-specific measurement lives in the PhoneArena and Notebookcheck methodologies.

원문에서 계속 ↗

코멘트

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다