Color and dead pixels
Black, white, and RGB solids are the fastest way to catch dead pixels, bright pixels, dark pixels, and obvious tint imbalance.
Click to start fullscreen inspection
Inspect dead pixels, bright pixels, and dark pixels
가장 자주 쓰는 화면 점검 항목을 한 페이지에 모아 단색 전환, 불량 화소 확인, 전체 화면 관찰, 브라우저 기준 장치 정보 확인을 함께 제공합니다.
Black, white, and RGB solids are the fastest way to catch dead pixels, bright pixels, dark pixels, and obvious tint imbalance.
Step ladders, gradients, and clipping views make it easier to catch banding, crushed shadows, and blown highlights.
Resolution and refresh views help inspect scaling, thin-line rendering, browser-side smoothness, and timing consistency.
If the overview already reveals a likely issue, jump into a more focused page for a deeper pass.
전체 화면 단색과 사용자 지정 HEX 색상을 이용해 색 편차, 불량 화소, 밝은 점, 암부 불균형을 확인합니다.
계단형 그레이스케일, 부드러운 그라데이션, 블랙/화이트 클리핑, 밴딩 패턴으로 계조 표현을 점검합니다.
정적인 단색과 수동 순환 모드를 이용해 잔상, 이미지 유지, 뚜렷한 번인 흔적을 확인합니다.
현재 해상도, DPR, 1px 선, 픽셀 그리드, 선명도 샘플을 확인해 브라우저 기준 화면이 얼마나 또렷한지 살펴봅니다.
requestAnimationFrame 으로 브라우저 측 주사율을 추정하고 간단한 모션 장면과 함께 부드러움과 흔들림을 관찰합니다.
This order mirrors how many people actually check a new monitor or troubleshoot a panel at their desk.
Use black, white, and RGB first to reveal dead pixels, bright pixels, glow, corner shading, and obvious tint shifts.
If the panel looks washed out, crushed, or uneven in tone, switch to ladders and gradients for a more sensitive read.
Use 1px lines, checker patterns, and text sharpness views to inspect scaling artifacts and rendering softness.
Once you know which direction to investigate, the dedicated color, grayscale, burn-in, resolution, or refresh pages will be more efficient.
The reading path stays below the workbench so the first screen stays usable without hiding the deeper context.
Solid-color patterns are the usual starting point for a quick display check because they are fast to read with the naked eye.
When solid colors look mostly fine, grayscale and fine-line views help dig deeper into tonal separation and rendering quality.
Each pattern is better at revealing a different class of display issue, so switching with intent saves time.
빠른 점검
암점, 백라이트 번짐, 기본 패널 균일성을 확인할 때 사용합니다.
빠른 점검
밝은 점, 먼지, 밝기 균일성을 빠르게 확인할 때 사용합니다.
빠른 점검
빨간 화면은 스턱 픽셀과 뚜렷한 색 편차를 드러내기 쉽습니다.
빠른 점검
초록 화면은 죽은 픽셀이나 스턱 픽셀을 눈에 띄게 확인하기 쉽습니다.
빠른 점검
파란 화면은 암부 모서리, 스턱 픽셀, 균일성 변화를 확인하는 데 도움이 됩니다.
빠른 점검
검은색과 흰색 사이의 계조 분리가 자연스러운지 빠르게 확인합니다.
빠른 점검
스케일링 아티팩트와 가장자리 선명도를 빠르게 확인하는 패턴입니다.
The reading path stays below the workbench so the first screen stays usable without hiding the deeper context.
Solid-color patterns are the usual starting point for a quick display check because they are fast to read with the naked eye.
Pure black helps reveal dark pixels, backlight glow, gray corners, and dark-scene uniformity shifts.
Pure white makes bright pixels, dust, stains, and bright-area uniformity issues easier to notice.
When solid colors look mostly fine, grayscale and fine-line views help dig deeper into tonal separation and rendering quality.
If neighboring tones merge too early or gradients band visibly, the display path is not separating tones smoothly enough.
Blurry or broken fine lines often point to system scaling, browser zoom, or rendering-path interpolation.
SPCBOX focuses on browser-reachable self-checks rather than pretending to expose low-level monitor truth.
Resolution, DPR, color depth, and refresh estimates come from the current browser environment and should be read as practical hints.
For absolute color accuracy, gamma curves, luminance calibration, or hardware response validation, dedicated physical instruments are still the right tool.
These answers clarify what a browser-based screen test can help with and where its limits begin.
No. It is best for fast dead-pixel, tint, grayscale, sharpness, and browser-side motion checks, not for replacing a calibrator or high-speed camera setup.
Fullscreen reduces browser chrome, nearby distractions, and layout edges, which makes glow, dead pixels, corner shading, and uniformity issues easier to spot.
Because this page estimates behavior through requestAnimationFrame, so the result is influenced by focus state, browser scheduling, and system load.
Not always. The overview is intentionally built for fast screening, and the focused pages are most useful once you already have a suspected direction.