HandBrake HDR Looks Wrong After Encode: How to Fix It

If HDR video looks dim, washed out, oversaturated, flat, or strangely colored after a HandBrake encode, the encode is not necessarily damaged. The usual causes are missing or mismatched HDR metadata, an unexpected tone-mapping choice, an 8-bit output, an incompatible codec or container, hardware encoder limitations, or a player and display chain that is not presenting HDR correctly. The fastest solution is to identify whether the problem comes from the encoded file or from playback rather than changing several unrelated settings at once.

This guide focuses specifically on HDR handling and playback expectations in HandBrake. It applies to Windows, macOS, and Linux users encoding authorized video files, personal disc sources, screen recordings, phone videos, or camera footage. Each troubleshooting step explains what to test, what success looks like, and when you can stop changing settings.

1. Confirm the Symptom With a Small Test Encode or Preview

Start with a short, representative section of the source rather than repeatedly encoding the entire video. Pick a scene containing both bright highlights and darker details, such as sunlight, lamps, reflections, clouds, faces, or shadowed clothing. A 30-second to two-minute sample is usually enough to reveal an HDR problem.

Use the same source, preset, filters, codec, and quality settings that produced the bad result. If the short test reproduces the problem, you now have a fast way to evaluate one change at a time. If it does not, the original problem may be limited to a specific scene, chapter, metadata change, or playback condition.

1.1 Identify the exact visual failure

• Dim image: The player or display may not be activating HDR, or HDR may be shown incorrectly on an SDR screen.
• Washed-out image: HDR transfer characteristics may be interpreted as ordinary SDR, causing raised blacks and weak contrast.
• Oversaturated or unnatural colors: The color primaries, transfer characteristics, or matrix may be missing, incorrectly signaled, or mishandled during playback.
• Clipped highlights: Tone mapping may be inappropriate, or the display may not be handling the encoded HDR range well.
• Banding in gradients: The output may be 8-bit, or aggressive compression may have removed subtle tonal steps.
• Correct on one device but wrong on another: The encode may be valid, but codec, container, HDR format, or metadata support differs between playback devices.

Do not use a web browser thumbnail, file manager preview, or basic screenshot as your only visual reference. Screenshots can pass through color-management or HDR-to-SDR conversion that does not represent direct video playback.

1.2 Compare the source and output in the same player

Open the original and encoded files in the same player on the same display. This controls several variables. If the source is also dim or washed out, the issue is probably the player, operating system HDR mode, display configuration, or source itself. If only the output is wrong, inspect the encode settings and metadata.

Next, test the output in a second reputable player if one is available. A file that looks correct in one player and wrong in another points to a playback compatibility issue. Success means the encoded sample has expected contrast, color, and highlight detail in at least one known HDR-capable playback chain. Once that result is repeatable, stop changing compression settings and investigate the incompatible player or device instead.

2. Check the HandBrake Settings Directly Related to HDR

HDR is not simply a brighter version of standard dynamic range. HDR video can use a different transfer function, wider color primaries, higher bit depth, and metadata that tells compatible equipment how to present the picture. Preserving only some of those properties can produce a file that decodes but does not look right.

2.1 Decide between HDR preservation and SDR conversion

Before adjusting settings, decide what the output is supposed to be. There are two different goals:

• Preserve HDR: Keep an HDR-compatible signal for an HDR-capable player and display.
• Create SDR: Tone map the HDR source into a conventional SDR output for broader compatibility.

HDR passthrough and tone mapping are not interchangeable. Preserving HDR means the output remains dependent on a compatible HDR playback chain. It may look wrong when an SDR player treats it as ordinary SDR. Tone mapping intentionally changes the picture so HDR brightness and color fit within SDR limits. The SDR result should look consistent on ordinary displays, but it will no longer provide the original HDR presentation.

If the final audience will watch mostly on office monitors, older televisions, projectors, browsers, or unknown devices, SDR conversion is often the safer choice. If the file is intended for a known HDR television, home theater system, or HDR editing environment, preserving HDR may be preferable.

2.2 Use a 10-bit-capable encoder for HDR output

For HDR preservation, select an encoder option that supports 10-bit output, such as an available 10-bit HEVC option. The exact encoder names shown depend on the operating system, installed hardware, and HandBrake build. Do not assume that every H.264, HEVC, AV1, or hardware option uses the same bit depth merely because the codec family can support HDR.

An 8-bit output may still play, but it is a poor default for preserving typical HDR sources and can increase visible banding. Check the completed file with a media-information utility or inspect HandBrake's Activity Log to confirm the output pixel format or bit depth.

Success means the output is reported as 10-bit, the test scene retains smooth gradients, and compatible HDR playback does not show new contouring. If the metadata and presentation are also correct, stop changing bit-depth settings. A higher bit depth by itself will not repair incorrect tone mapping or an incompatible display.

2.3 Review HDR metadata and color signaling

HDR10 commonly relies on signaling that identifies the transfer characteristics and wide-color primaries, with mastering display and content light information potentially included. The source may contain some or all of this metadata. Dynamic HDR formats can introduce additional compatibility requirements, and not every workflow preserves every proprietary or dynamic metadata layer.

Inspect the source before assuming HandBrake removed HDR. Phone and camera footage can use HLG, PQ-based HDR, vendor-specific profiles, or variable metadata. Screen recordings may be tagged inconsistently. If the source metadata is incomplete or unusual, the encoder cannot always infer the creator's intended presentation.

In the Activity Log, look for references to 10-bit pixel formats, color primaries, transfer characteristics, color matrix values, mastering display information, content light levels, HDR10, PQ, or HLG. The exact wording varies with the source and encoder. Compare the source scan with the output configuration rather than searching for one magic line.

Success means the output carries color and HDR signaling appropriate to the intended format, and the player activates HDR when expected. Once both the metadata inspection and real display test agree, do not keep changing filters or quality values.

2.4 Disable unnecessary video filters during diagnosis

Filters can alter pixel formats, color processing, frame structure, or the encoder path. For a clean diagnostic encode, disable filters you do not need, including denoising, sharpening, deinterlacing, decomb, grayscale processing, and color-related adjustments. Keep a filter only when the source genuinely requires it.

Some filters are valid in an HDR workflow, but they make troubleshooting harder because they add another transformation. Success means a filter-free test restores correct HDR behavior. Re-enable required filters one at a time and test after each change. Stop when you identify the first filter or combination that changes the result.

3. Check the Entire Source-to-Display Chain

HandBrake creates the file, but the final image also depends on the source, destination format, player, operating system, graphics driver, cable, receiver, and display. A correct HDR encode can look wrong if any component interprets it as SDR or cannot decode the chosen format.

3.1 Verify the source is genuinely HDR

Check the original with a media-information tool and a player known to support the source's HDR format. Do not identify HDR from resolution alone. A 4K video can be SDR, while a lower-resolution video can carry HDR signaling.

If the original already has crushed shadows, odd colors, or missing metadata, a normal transcode will usually preserve or expose those problems rather than repair them. Success means the original is confirmed as HDR and plays correctly on a known-compatible system.

3.2 Match the codec and container to the playback device

A modern codec may support 10-bit HDR, but a specific television, streaming box, browser, editor, or phone may support only certain profiles, levels, containers, or metadata combinations. MP4 and MKV are containers, not image codecs. Choosing a compatible codec inside an unsupported container can still cause playback trouble.

Test the intended combination before encoding a large library. For broad HDR device compatibility, HEVC Main 10 in a supported container is common, but actual support must be checked for the target device. AV1 HDR support is growing, yet older hardware may lack decoding support. H.264 compatibility is broad, but device support for 10-bit H.264 is much less predictable.

Success means the target device decodes the file smoothly, switches into the expected HDR mode, and displays normal colors. If another container or codec solves the problem without changing the image settings, the issue was compatibility rather than tone mapping.

3.3 Compare software and hardware encoders

Hardware encoders can be fast, but capabilities vary by GPU generation, driver, operating system, codec, profile, and bit depth. An encoder appearing in HandBrake does not guarantee that every HDR-related feature is available in every combination.

Create one short sample with the selected hardware encoder and another with a software 10-bit encoder using otherwise similar settings. The files do not need identical sizes. You are testing HDR signaling and visual behavior, not conducting a quality contest.

If the software encode works and the hardware encode does not, update the graphics driver from the hardware vendor and recheck the selected profile and bit depth. If the problem remains, use the software encoder for this source or choose a hardware mode proven to preserve the required output. Success means both the log and output confirm the intended 10-bit HDR path.

3.4 Test HDR and SDR displays separately

Play the sample on an HDR-capable display with HDR enabled in the operating system and display settings. Confirm that the display actually enters HDR mode if it provides an indicator. Then test the same file on an SDR display.

A preserved HDR file may look poor on an SDR system if the player does not tone map it. That does not automatically mean the encode failed. Conversely, an SDR tone-mapped file should look normal on SDR displays but should not be expected to trigger HDR mode on an HDR television.

• Expected HDR result: HDR mode activates, highlights and colors look natural, and shadow detail remains usable.
• Expected SDR result: The picture looks balanced without requiring HDR mode, with bright HDR values compressed into the SDR range.

Stop adjusting HandBrake when each output behaves according to its design. If you need one file to work reliably everywhere, an SDR conversion may provide a more predictable result than preserved HDR.

3.5 Rule out unrelated destination, audio, and subtitle factors

A destination drive does not normally change HDR color. However, an incomplete file caused by insufficient disk space, a disconnected external drive, or an interrupted encode can fail or play unpredictably. Confirm that the encode completed and that the file can be read without errors.

Audio track selection does not normally affect HDR video. If playback fails only on one device, however, an unsupported audio codec may cause that device or application to reject the entire file. Test with a common stereo audio track when isolating compatibility.

Subtitle tracks also do not normally change HDR signaling. Burned-in subtitles require rendering into the video and therefore alter the video-processing path. During diagnosis, disable burned subtitles unless they are essential. If the clean test works, add the required subtitle configuration back and retest.

4. Use the Activity Log to Separate Guesswork From Evidence

The HandBrake Activity Log records the source scan, selected tracks, filters, encoder, pixel format, and messages produced during the job. It is the most useful evidence when HandBrake troubleshooting goes beyond an obvious preset mistake.

4.1 What to look for in the log

• The source video codec, resolution, frame rate, and pixel format
• Whether the source is reported as 10-bit
• Color primaries, transfer characteristics, and matrix information
• PQ, HLG, HDR10, mastering display, or content light references
• The exact software or hardware video encoder selected
• The output profile, level, pixel format, and bit depth
• Enabled filters and any color-conversion stage
• Warnings, fallback behavior, unsupported options, or encoder errors
• The final completion status

Save the log from the failed short test before changing settings. Then run one corrected test and compare the two logs. If an intended 10-bit encoder silently changed, a filter was enabled, or a hardware path rejected an option, the difference may be visible in the log.

Success means the log confirms the settings you believed you selected and the completed file behaves accordingly. If the log is correct but one player remains wrong, focus on playback support instead of repeatedly re-encoding.

4.2 Interpret metadata clues carefully

Metadata presence does not guarantee correct visual output, and a missing optional field does not always make a file invalid. Treat metadata as one part of the evidence. The decisive test combines source inspection, log inspection, output inspection, and playback on the intended display.

If the source is tagged as HLG but the target expects a different HDR workflow, or if a dynamic HDR source is converted to a more basic HDR representation, the output may not match every aspect of the original presentation. Establish which HDR format you need to preserve before concluding that HandBrake is not working.

5. Run a Clean Temporary Encode With Minimal Settings

When several settings have been changed over time, create a clean diagnostic job rather than repairing the old queue entry. This avoids inherited filters, custom encoder arguments, and track settings.

1. Open the original source again and allow HandBrake to rescan it.
2. Select a short range containing bright and dark details.
3. Choose a simple preset appropriate to the source resolution.
4. Select a 10-bit-capable software encoder if preserving HDR.
5. Disable optional video filters and custom encoder arguments.
6. Use a compatible container for the target player.
7. Select one ordinary audio track and omit subtitles temporarily.
8. Encode to a local drive with sufficient free space.
9. Save the Activity Log and inspect the completed file's properties.
10. Test on a known HDR-capable display and, separately, an SDR display.

If the clean encode works, add necessary features back one at a time. Start with required subtitles or audio, then filters, then hardware encoding. Test after every addition. This method identifies the actual trigger without creating a confusing combination of changes.

If the clean HDR encode still fails on every confirmed HDR playback chain, create a short SDR tone-mapped test. If that result looks correct across devices, SDR conversion is a practical fallback, especially when compatibility matters more than retaining HDR.

6. Quick Fix Checklist

• Confirm that the source is truly HDR and note whether it uses PQ, HDR10, or HLG.
• Decide whether the output should preserve HDR or be tone mapped to SDR.
• Use a 10-bit-capable encoder when preserving HDR.
• Disable unnecessary filters during the test.
• Confirm the output codec, profile, bit depth, and container suit the target device.
• Compare software and hardware encoder samples.
• Update the graphics driver if the hardware path behaves differently.
• Read the Activity Log for metadata, pixel-format, fallback, and error clues.
• Test the source and output in the same player.
• Test the output on both an HDR-capable display and an SDR display.
• Verify that HDR is enabled in the operating system and display configuration.
• Use SDR conversion when reliable playback on unknown devices is the priority.

Stop changing settings as soon as the short sample meets its intended goal. For HDR preservation, success means the compatible display activates HDR and presents natural contrast, colors, highlights, and shadow detail. For SDR conversion, success means the file looks balanced on an SDR display without depending on HDR activation.

7. Frequently Asked Questions

7.1 Why does my HandBrake HDR encode look dim?

The most common reason is that preserved HDR is being displayed without correct HDR activation or tone mapping. Confirm that the operating system, player, connection, and display all support the output's HDR format. If the file is intended for an SDR screen, create a tone-mapped SDR output instead of expecting HDR passthrough to look correct.

7.2 Why does the output look washed out?

A washed-out picture often means the HDR transfer function is being interpreted as SDR or the color signaling is not being handled correctly. Compare the file in another HDR-aware player, verify 10-bit output and HDR metadata clues in the Activity Log, and check whether the display enters HDR mode.

7.3 Does choosing a 10-bit encoder automatically preserve HDR?

No. Ten-bit encoding helps preserve tonal precision and is normally appropriate for HDR, but it does not by itself guarantee correct transfer characteristics, color primaries, metadata, codec compatibility, or playback. Treat bit depth as one requirement within the complete HDR chain.

7.4 Should I use a hardware encoder for HDR?

You can use one when the hardware, driver, selected codec, profile, and bit depth support the required workflow. If the result is wrong, compare it with a short software 10-bit encode. A correct software result and incorrect hardware result point toward a hardware-path limitation or configuration issue.

7.5 Why does the encode look correct on my TV but wrong on my computer?

The television may support the file's HDR format while the computer player, operating system HDR mode, monitor, graphics driver, or connection does not. Since the file works on a confirmed HDR device, investigate computer playback before re-encoding. If computer compatibility is essential, test a different player or create an SDR version.

7.6 When should I convert HDR to SDR?

Choose SDR when the audience uses mixed or unknown displays, when the destination platform does not reliably support the HDR format, or when consistent appearance matters more than preserving HDR highlights and wide color. A properly tone-mapped SDR file is often safer for older televisions, ordinary monitors, projectors, and broad sharing.