HandBrake Subtitles Appear Garbled: How to Fix Characters and Encoding

When HandBrake subtitles appear garbled, the video may show boxes, question marks, replacement symbols, broken accented letters, or mojibake such as ’ instead of an apostrophe. This usually does not mean the subtitle track is missing. It means the subtitle text was decoded incorrectly, saved with an unsuitable character encoding, rendered with a font that lacks the required characters, or interpreted differently by the output container or playback app. The fastest solution is to test a short sample, verify the external SRT file, and determine whether the corruption exists in the encoded subtitle data or only during playback.

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

Do not begin by changing every video, audio, and encoder setting. First, reproduce the problem with a short section containing the affected characters. A subtitle line with an accented name, curly quotation marks, non-Latin writing, or unusual punctuation is a useful test point.

1.1 Identify What Garbled Means in Your Output

Different visual symptoms point to different causes:

• Sequences such as ’, é, or  commonly indicate that UTF-8 text was interpreted as a legacy encoding.
• Empty squares or rectangular boxes commonly indicate that the selected playback font lacks the required glyphs.
• Question marks may mean characters were already lost when the subtitle file was converted or saved.
• A black diamond containing a question mark is often a replacement character inserted when text cannot be decoded.
• Correct basic English text but broken accented or non-Latin characters usually points to encoding or font coverage.
• Correct burned-in subtitles but broken soft subtitles usually points to the player, container, or subtitle renderer.

If subtitles are absent entirely, this article is not the closest troubleshooting path. Confirm that the intended subtitle track was added and enabled before investigating character display.

1.2 Encode Only a Short Range

Use HandBrake's range controls to encode a short chapter or a small interval around a known bad subtitle line. Keep the same source, subtitle file, container, and subtitle behavior used in the failed job. A short test makes every later comparison faster.

Play the sample in at least two reputable playback applications when possible. If one player displays the text correctly and another does not, the encoded file may be valid and the problem may be limited to player rendering. If every player shows the same corruption, inspect the subtitle file and HandBrake's subtitle import settings.

Success means the chosen test line appears exactly as it does in the corrected source text. Once that happens, stop changing unrelated video settings and repeat the full encode using the successful subtitle configuration.

2. Check the HandBrake Settings Directly Related to This Problem

The settings that matter most are the selected subtitle track, the character encoding used for imported text subtitles, and whether subtitles are burned into the picture or stored as a selectable track.

2.1 Verify the External SRT Character Encoding

An SRT file is a plain-text file containing sequence numbers, timestamps, and subtitle text. The bytes in that file must be interpreted with the correct character encoding. UTF-8 is the safest general choice because it can represent accented letters, typographic punctuation, and writing systems from many languages.

Legacy encodings such as Windows-1252, ISO-8859 variants, or language-specific code pages can also represent valid SRT files. Problems arise when a file saved in one encoding is read as another. For example, UTF-8 bytes decoded as Windows-1252 can produce recognizable mojibake rather than the intended punctuation.

When importing an external SRT, review the character encoding option associated with that subtitle entry. Select UTF-8 if the file is genuinely UTF-8. Do not select UTF-8 merely because it is modern if the source file is still stored in a legacy encoding. The setting must describe the actual file.

Success means the short encode reproduces accents, apostrophes, currency symbols, and non-English characters correctly. At that point, there is no benefit in changing the video codec, quality slider, or audio tracks.

2.2 Understand Burned-In and Soft Text Subtitles

Burned-in subtitles are rendered into the video frames during encoding. They cannot be turned off later. Because the resulting characters become pixels, every player should show the same appearance. This makes a burned-in sample a useful diagnostic tool, although it is not always the desired final format.

Soft text subtitles remain a separate selectable track inside the output container. The playback application chooses the font and performs the final rendering. Therefore, the same soft subtitle track can look correct in one app and appear as boxes or broken text in another.

Use this comparison diagnostically:

1. Create a short burned-in test from the corrected subtitle file.
2. Create a second short test with the subtitle stored as a soft track, if the selected container supports the intended subtitle format.
3. Play both samples in the same application.
4. Test the soft-subtitle sample in another player.

If burned-in text is correct but the soft track is garbled only in one player, the source encoding is probably no longer the main problem. Focus on that player's subtitle font, renderer, language support, and updates.

2.3 Check the Selected Track Without Rebuilding Everything

Sources can contain several subtitle tracks, while an external SRT adds another candidate. Confirm that the subtitle list contains the intended track and that the test output is displaying that same track. Language labels are helpful but are not definitive because tracks can be mislabeled.

Do not change audio tracks to fix malformed subtitle characters. Audio selection does not decode SRT text. Similarly, switching between H.264, H.265, AV1, software encoding, and hardware encoding is unlikely to repair text encoding. Those controls affect video compression, not how an external SRT's bytes map to characters.

3. Inspect the Source Subtitle File Before Encoding

If HandBrake subtitles are garbled in every test player, inspect the subtitle source directly. This is often the most important step because HandBrake cannot restore characters that were already replaced or damaged before import.

3.1 Open the SRT in a Text Editor

Use a text editor that can identify and convert encodings. Suitable options include modern code editors and established text editors with explicit encoding controls. Avoid relying only on a basic viewer that silently guesses the encoding.

Navigate to the exact line that failed in the video and check the following:

• Does the editor show the intended accented or special characters?
• Does the status bar or encoding menu identify UTF-8, UTF-8 with BOM, or a legacy code page?
• Are the line numbers and timestamps still formatted as valid SRT entries?
• Are replacement characters already present in the file?
• Does switching the editor's interpretation to another likely encoding restore the original text?

Be careful with the difference between reopening and converting. Reopening a file with the correct legacy encoding tells the editor how to interpret the existing bytes. Converting then saves those correctly interpreted characters as UTF-8. Simply labeling incorrectly decoded text as UTF-8 preserves the visible corruption.

3.2 Save a Corrected Copy as UTF-8

Once the editor displays the text correctly, save a new copy as UTF-8. Keep the original file untouched so you can recover from an incorrect conversion. Give the corrected copy a clear name, such as movie.en.utf8.srt.

After saving, close the file and reopen it. Confirm that the same test line remains correct. This reopening step verifies that the conversion was actually written to disk rather than displayed temporarily.

If the file already contains question marks where letters should be, changing the encoding may not recover them. A question mark can be a literal replacement written during an earlier destructive conversion. Restore the subtitle from an undamaged source or correct the affected lines manually.

Success means the newly saved SRT opens correctly as UTF-8 and produces a clean short encode. Use that corrected file for the full job and stop experimenting with legacy encoding choices.

3.3 Preserve Valid SRT Structure

Encoding conversion should not disturb subtitle timing. A typical entry contains a sequence number, a timestamp line, subtitle text, and a blank separator. If an editor or conversion utility changes punctuation in timestamps, removes blank lines, or saves rich-text formatting, import can fail or behave unpredictably.

Save as plain text with the .srt extension. Avoid word processors because they may introduce formatting, smart punctuation, or metadata that does not belong in a plain-text subtitle file.

4. Check Container, Player, Font, and System Factors

Once the SRT itself is valid, determine where rendering occurs. Output container capabilities and playback software can affect how selectable subtitles are stored, styled, and displayed.

4.1 Compare the Output in More Than One Player

Players use different subtitle engines and fallback-font rules. A television, streaming box, browser-based player, phone app, and desktop player may render the same track differently. Embedded devices can have particularly limited font coverage.

If only one device shows boxes, test the file on a desktop player. If it works there, check the affected device for firmware updates, language settings, supported subtitle formats, and available subtitle fonts. Re-encoding the video at a different quality will not add missing glyphs to a playback device.

Success means the soft subtitle track displays correctly in a player known to support its characters. You can then decide whether to use a compatible player, choose a better-supported subtitle workflow, or burn in the subtitles for consistent appearance across restricted devices.

4.2 Distinguish Encoding Failure From Missing Font Glyphs

An encoding failure usually transforms characters into other characters, often producing repeated patterns such as à or â. A font failure more often produces boxes while leaving supported characters intact. For example, Latin letters may display normally while a different script becomes a row of squares.

For soft subtitles, select a player subtitle font with broad coverage for the required writing system. On Windows, macOS, and Linux, the exact font inventory differs. Installing or selecting an appropriate font may solve playback boxes without another HandBrake encode.

For burned-in subtitles, rendering occurs during the HandBrake job. If only certain scripts fail in a burned-in test, verify that the system has a suitable font and that the source text itself is valid. Restarting the application after installing a font may be necessary before retesting.

4.3 Rule Out Unrelated Components

The destination drive can cause a failed or incomplete write, but it does not normally turn valid subtitle letters into mojibake. Verify free space and file integrity if the encode stops, the output is truncated, or the file will not open. Those are different symptoms.

Graphics drivers and hardware video encoders can affect video stability or performance, but external SRT character decoding is not ordinarily repaired by changing them. Switch to a software video encoder only if the Activity Log reports a hardware encoder failure or the picture itself is corrupted.

Likewise, audio track selection has no direct effect on subtitle character encoding. Keep one known-good audio track in diagnostic encodes, but do not spend time changing audio codecs when the only symptom is unreadable subtitle text.

5. Use the Activity Log to Separate Guesswork From Evidence

HandBrake's Activity Log records how the source was scanned, which tracks were selected, what output was requested, and whether errors occurred. Open the log for the short failed test rather than relying only on the queue summary.

5.1 What to Look For in the Log

• Confirmation that the intended subtitle source or imported SRT was included.
• The subtitle language and relevant import settings.
• The chosen container and whether the subtitle was burned or passed as a selectable track.
• Warnings about reading the subtitle file or unsupported output behavior.
• Errors indicating that the encode ended early or the output could not be written.

The log may not explicitly diagnose every incorrect character encoding. Its value is in confirming what HandBrake actually processed. If the log shows the expected SRT and a completed encode, but only one player renders boxes, investigate the player. If the wrong subtitle track was selected, correct that selection before modifying fonts or codecs.

Keep the log from one failed sample and one successful sample. Compare only the subtitle-related differences. Once the corrected UTF-8 file and intended subtitle mode produce a clean result, stop changing settings.

6. Run a Clean Temporary Encode With Minimal Settings

A controlled encode removes variables without requiring a full HandBrake reset. Use a local source file and write to a simple local destination with sufficient free space. Work only with media you have the right to process.

6.1 Minimal Diagnostic Workflow

1. Open the source and select a short range containing a visibly broken subtitle line.
2. Choose a standard preset appropriate for your computer and leave advanced video options unchanged.
3. Select one known-good audio track.
4. Remove unrelated subtitle tracks from the test.
5. Import the corrected UTF-8 SRT.
6. Set its character encoding to match the saved file.
7. Create a burned-in test and, if needed, a separate soft-subtitle test.
8. Save to a new local filename instead of overwriting an earlier output.
9. Review the Activity Log and play the result in two applications.

This workflow separates three outcomes. If both tests are garbled, return to the SRT text and encoding. If burned-in text is correct but soft text fails everywhere, examine container and soft-subtitle compatibility. If soft text fails in only one player, change that player's renderer or font rather than repeating the encode.

7. Quick Fix Checklist

• Find one subtitle line containing the broken characters.
• Open the external SRT in an encoding-aware plain-text editor.
• Interpret the original file with its actual encoding before converting it.
• Save a separate corrected copy as UTF-8.
• Close and reopen the copy to verify that its characters survived.
• Import the corrected SRT and select the matching encoding in HandBrake.
• Run a short encode instead of processing the entire video.
• Compare burned-in and soft subtitle behavior when practical.
• Test the output in at least two playback applications.
• Choose a font with glyphs for the required language or script.
• Read the Activity Log to confirm which subtitle HandBrake processed.
• Do not change video, audio, driver, or hardware encoder settings without related evidence.

The issue is fixed when the known test line displays correctly, the Activity Log confirms the intended subtitle workflow, and the output works in the player or device you plan to use. At that point, repeat the full encode with the same successful settings.

8. Frequently Asked Questions

8.1 Why Do Apostrophes Appear as ’ in HandBrake Subtitles?

This is a classic encoding mismatch. The subtitle was often saved as UTF-8 but interpreted as a legacy encoding such as Windows-1252, or corrupted during an earlier conversion. Open the original SRT with the correct interpretation, confirm that the apostrophe appears properly, and save a new UTF-8 copy before importing it again.

8.2 Why Do I See Boxes Instead of Letters?

Boxes usually indicate missing font glyphs. If the subtitles are soft, try another player or select a font that supports the language. If they are burned in, verify that the operating system has a suitable font and that the SRT characters display correctly in a text editor.

8.3 Should I Add a UTF-8 BOM to an SRT File?

Many modern tools can read UTF-8 with or without a byte order mark. The more important requirement is that the file truly contains valid UTF-8 and that it is imported as such. If a particular application detects only the BOM-marked form reliably, saving UTF-8 with BOM may help, but test a short sample rather than assuming it is required.

8.4 Why Are Burned-In Subtitles Correct but Selectable Subtitles Garbled?

Burned-in subtitles become pixels during encoding, while selectable subtitles are rendered later by the playback application. Correct burned-in text shows that HandBrake could interpret and render the source. The soft-subtitle failure is then more likely related to the player, output container, supported subtitle format, or available fonts.

8.5 Will Changing the Hardware Encoder Fix Garbled Subtitle Characters?

Usually not. Hardware and software video encoders compress the picture. They do not normally determine how an external SRT maps bytes to characters. Change the video encoder only when the log reports an encoder problem or the video itself is corrupt.

8.6 Can HandBrake Recover Characters Already Replaced With Question Marks?

Not usually. If literal question marks were saved over unsupported characters during a previous conversion, the original information is gone from that copy. Restore an undamaged subtitle file or repair the text manually, then save the corrected version as UTF-8 and test it before the full encode.