What this tool helps you verify

HDR Display Capability Test

Check if your monitor or mobile screen supports HDR (High Dynamic Range). Visually compare SDR vs. HDR colors and test screen brightness and color depth.

HDR TestMonitor CheckColor TestBrightnessWide Gamut
Privacy

Avoids unrelated permissions and runs in your browser with the device APIs available on this device.

Supported platforms

Works best in current Chrome, Edge, Safari, and Firefox. Support depends on CSS media queries and display capability APIs, secure HTTPS, hardware availability, and browser policy.

Visual comparison (for "subjective judgment")
Recommendations: Full screen, turn off Night Sight/Eye Protection, turn on system HDR, and increase the brightness; then observe "whether the highlights are obviously brighter and whether there are layers in the shadows."
Black(0)
rgb(0 0 0)
SDR White (1.0)
rgb(255 255 255)
SDR gray scale (0→1)
"HDR Try" highlight gradient (requires CSS Color 4 + HDR output link)
Note: "The browser can display HDR" and "can decode HDR video" are two different things; and even if it supports it, it may be affected by the system HDR switch, color management, external monitor, and player path.
Local video loading (recommended HDR video shot with your device)
iPhone/some Android "HDR/Dolby Vision" materials are the most valuable for reference; if the picture is gray or the highlights are not bright during playback, it may be that the HDR output link is not turned on or is being transferred to SDR.
resolution
-
duration
-
hint
Try to play it in full screen and observe the highlights
Display/browser capabilities
Conclusion (experience):More likely SDR output
dynamic-range: high
unknown
color-gamut: rec2020
unknown
color-gamut: p3
unknown
CSS color(display-p3)
unknown
CSS color(rec2020)
unknown
CSS rec2020 > 1(HDR)
unknown
Reminder: Some systems will force SDR under "External Display/Screen Mirroring/Power Saving Mode/Night Shift"; even if the display is HDR, it may be downgraded.
HDR video decoding capability detection (MediaCapabilities)
"Supported" doesn't necessarily mean displaying in HDR; it's closer to "decodable." Whether HDR output still depends on the system/monitor/player path.
FormatSupport decodingfluencyPower saving
SDR: H.264/MP4 (1080p@30)---
HDR10: HEVC Main10/MP4 (4K@30, PQ/Rec2020)---
HLG: HEVC/MP4 (4K@30, HLG/Rec2020)---
HDR: VP9 Profile 2/WebM (4K@30, PQ/Rec2020)---
HDR: AV1/WebM (4K@30, PQ/Rec2020)---
Explanation: smooth/powerEfficient can often be used to "guess whether to use hard solution/hardware acceleration", but it is still subject to actual playback.

How to use this page to quickly determine whether HDR "really takes effect"

First look at "dynamic-range: high" and "color-gamut: rec2020" on the right side: both are "yes" at the same time, which makes it more like an HDR output link.
Look at "CSS rec2020 > 1 (HDR value)" again: If it is "Yes", use the highlight color block (1.2/1.6/2.0) in the top "Visual Comparison" to compare with SDR white. Normal HDR will be "brighter" and have more "highlight impact".
Even if the "Decoding Support" shows that it supports HDR10/HLG, it may be converted to SDR playback by the system/browser (a common phenomenon is that the overall image is gray and the highlights are not bright). Be sure to use the HDR material you shot/downloaded to confirm.
External monitors/screen projection/power saving mode/eye protection mode/night viewing often trigger SDR degradation; it is recommended to first use the built-in screen, turn off night viewing, increase the brightness, and go to full screen before observing.

HDR Guide

Combine capability scan with visual high-light checks.

Step 1

Make a “capability judgment” first

about 10 seconds

Determine whether the HDR output link may be enabled through the browser's media query/CSS support.

Observe the results such as "dynamic-range: high" and "color-gamut: rec2020" on the right
If dynamic-range: high is No, it can basically be processed as SDR (unless the browser/system does not expose this capability)
If rec2020/p3 is yes, it means that there is at least the possibility of wide color gamut output
Step 2

Do visual highlight contrast

about 20 seconds

Observe "whether the highlights are brighter and whether the dark parts have layers" through color blocks and gradients.

Click "Full Screen Contrast", increase the system brightness, and turn off Night View/Eye Protection
Compare SDR White vs “HDR Highlight (1.6/2.0)”: If there is almost no difference, the common reason is that it was converted to SDR
Compare SDR grayscale: whether the dark parts (close to black) can be separated into layers and whether they are "blurred"
Tip: The "highlight impact" of different devices varies greatly; please give priority to "same-machine comparison" (HDR on/off, different browsers, external/internal screens).
Step 3

Live broadcast confirmation using HDR material

about 30 seconds

Loading a local HDR video (shot/downloaded on a mobile phone) and actually playing it is one of the most reliable ways to judge.

Upload a video that you confirm is HDR (for example, a clip recorded by "HDR Video" on your mobile phone)
Observe after full-screen playback: whether highlights (lights/reflections/sky) are significantly brighter, and whether details are still retained in dark areas
If "the whole is gray/the highlights are not bright/the color is strange", it is mostly due to HDR→SDR conversion or color management problems; you can change the browser/change the player path to verify

What this tool checks

This page checks whether the browser and display pipeline expose useful HDR-like capability signals and visible contrast differences.

browser HDR capability hints

Looks for browser-visible display capability signals such as relevant media-query or rendering behavior.

highlight differentiation

Helps you see whether bright areas separate clearly or collapse into a flat SDR-like look.

shadow and contrast visibility

Makes it easier to notice whether darker detail is still visible without crushing.

color depth clues

Useful for spotting obvious banding or limited-looking gradients.

fullscreen display behavior

Lets you compare whether the display pipeline changes when the test is shown fullscreen.

user-side visual sanity check

Provides a practical browser-level impression before deeper display calibration work.

What this tool cannot confirm

This is a visual HDR readiness check, not a calibrated measurement of panel brightness or color accuracy.

not a calibration report

It cannot certify peak brightness, absolute nits, gamut coverage, or EOTF accuracy.

OS tone mapping affects the result

System HDR toggles, browser tone mapping, and display profiles can all change what you see.

screenshots can be misleading

Captured images often flatten HDR into SDR and do not represent the real visual result.

visual judgement is subjective

Ambient lighting and your own eyes still affect how strongly HDR differences appear.

How the result is generated

The result is generated from browser-visible display capability hints and from the local rendering of contrast and color test patterns.

01

display capability read

The page checks the browser and platform for relevant display capability signals.

02

pattern rendering

Highlight, shadow, and gradient content is rendered directly in the browser.

03

fullscreen comparison

You can compare whether the browser behaves differently when the content is shown fullscreen.

04

visual observation

You inspect whether highlight separation, color smoothness, and contrast look improved.

05

local interpretation

The page summarizes browser and visual cues rather than claiming a calibrated HDR certification.

Interpret your results

Use the result as a browser-level hint about HDR readiness, not as the final word on display quality.

Observed HDR resultLikely meaning
No HDR difference visibleThe display path may still be running in SDR, or the browser is not exposing an HDR-ready pipeline.
Highlights look washed outTone mapping, brightness settings, or browser display handling may be limiting contrast.
Strong banding visibleLimited effective bit depth, SDR path, or browser rendering constraints.
Fullscreen looks better than windowedThe system or browser may switch display behavior in fullscreen mode.
Highlights and gradients look clearly improvedThe browser and display path are likely exposing useful HDR-like behavior.

Supported browsers and known limitations

HDR-related browser behavior depends heavily on the OS display pipeline, browser support, and the monitor or device itself.

browsercapability hint exposurevisual HDR test supportfullscreen behaviorknown limitations
ChromeGood on supported systemsGoodGoodActual HDR path depends heavily on OS and display configuration.
EdgeGood on supported Windows setupsGoodGoodResults vary with Windows HDR settings and GPU path.
FirefoxMore limited browser exposureBasicBasicHDR-related web behavior is less consistent than on Chromium.
SafariPlatform-dependentBasic to goodGoodApple display pipeline behavior can differ sharply by device.
iOS SafariDevice-dependentBasicBasic to goodMobile tone mapping and brightness policies can dominate the result.
Android ChromeVaries by Android hardwareBasic to goodBasic to goodVendor display modes can change the perceived result.

Use cases

This test is useful when you want a quick browser-level sense of whether HDR-related display features are active enough to notice.

after enabling HDR in the OS

Check whether the browser now shows clearer highlight and gradient separation.

before watching HDR-like content

Verify whether the browser display path appears ready for a better dynamic-range experience.

when comparing browsers

See whether one browser exposes more convincing visual HDR cues than another.

after connecting a new monitor

Confirm whether the external display path changes the browser result.

when a screen looks flat

Use the test to decide whether the browser may still be stuck in an SDR-style pipeline.

FAQ

Focusing on the differences between HDR output, color gamut, decoding and actual look and feel, we have sorted out the most common judgment and troubleshooting paths.

1.

Can this page "measure the maximum brightness of the screen (nits)"?

cannot. Browsers generally cannot directly read the absolute upper limit of brightness (nits) of the screen. This page provides a combination of "capability detection + subjective comparison": use dynamic-range/color-gamut/MediaCapabilities to determine the possibility of support, and then use highlight contrast and HDR material live broadcast to confirm whether it is really output in HDR.

2.

dynamic-range: high = Yes, does it have to be HDR?

Not necessarily, but it’s a strong signal. dynamic-range: high reflects the browser's judgment of "high dynamic range output capability"; actual HDR is also affected by the system HDR switch, external monitor, color management, and player path. It is recommended to do "Highlight Color Block Comparison" and "HDR Video Live Confirmation".

3.

The decoding detection shows that HDR10/HLG is supported, but the picture looks like SDR. Why is this?

Very common. Decoding support only means "can decode this type of code stream", it does not mean that the output will be displayed in HDR. In many cases, browsers/systems will perform tone mapping on HDR content and convert it to SDR (showing that the overall content is gray and the highlights are not bright). Please make sure that system HDR is turned on, night view/eye protection is turned off, and try to play it in full screen on the built-in screen before making a judgment.

4.

Why are HDR results different on the same device on different browsers?

Different browsers have different HDR pipelines, color management, hard decoding strategies, and implementation of CSS Color 4 / MediaCapabilities. Especially HEVC/HDR10 has greater differences under different system licenses. It is recommended to compare Chrome/Edge with Safari/Firefox at least once (if available).

5.

CSS rec2020 > 1 (HDR value) shows "not supported", what does it mean?

This usually means that the browser does not support "HDR highlight values ​​beyond 1" expressed directly in CSS, or the current output link does not allow it. Even so, the device may still implement HDR through the "video playback pipeline" (such as when playing HDR video). Therefore, this capability is more biased towards "web page rendering HDR highlights" and is not equivalent to "video HDR".

6.

What footage should I use to verify HDR effects?

It is recommended to use HDR video shot with your mobile phone ("HDR Video/Dolby Vision" for iPhone/some Androids), or test footage that you confirm is HDR10/HLG. Loading and playing it as a local file, and then observing the highlights and shadow details, is one of the most intuitive and reliable ways.

7.

Will external monitor/screen projection affect HDR judgment?

meeting. External monitors, docking stations, screen casting protocols, and system "mirror/extended" modes can all cause HDR degradation or color management changes. It is recommended to test on the built-in screen first for benchmarking, and then test the external link for comparison.

Feedback / report a bug

Tell us your browser, device, and what happened.

Did this result look wrong?

Comments(0)

0
0