Subtitle Shows Boxes or Question Marks: Fix Encoding

You open a subtitle file and the text is boxes, question marks, or a run of symbols that were never in the script. Nothing is wrong with the words. The file is being read with the wrong character encoding, and the fix is almost always the same one line of housekeeping.

Why it happens

A text file is bytes. An encoding is the agreement about what those bytes mean. Save a file using one agreement, open it with a different one, and every character outside the plain English range comes out wrong. The Japanese word for the result, mojibake, has become the standard name for it.

English-only subtitles usually get away with this, because the basic Latin letters land on the same bytes in most encodings. Everything else does not. Urdu, Arabic, Hindi, Persian, Chinese, and even European accented characters break the moment the reader guesses wrong.

There is a second cause worth ruling out. If the encoding is right and you still see boxes, the font may simply have no glyph for that script. Boxes in one player and correct text in another usually points at the font rather than the file.

The fix: save as UTF-8

UTF-8 covers every script you are likely to caption in, and it is what players, platforms and editors expect. Re-saving the file as UTF-8 resolves almost every case.

• In most text editors the option is under Save As, in an encoding dropdown next to the file name.
• Prefer plain UTF-8 over UTF-8 with BOM. A byte order mark is an invisible marker at the very start of the file, and some subtitle players show a stray character before the first caption or fail to read the first cue because of it.
• Save a copy rather than overwriting, so you still have the original if the first attempt reads the bytes wrong and bakes the damage in.

Do not re-save a file that is already garbled

This is the mistake that turns a recoverable file into an unrecoverable one. If a file is displaying as mojibake and you save it in that state, you are writing the wrong characters permanently. The original bytes are gone.

Go back to the source file instead and open it with the correct encoding first, then save that as UTF-8. If the source is gone, regenerating the captions from the video is usually faster than repairing the damage by hand.

Where this bites hardest

Non-Latin scripts are where encoding stops being a footnote. An Urdu or Hindi subtitle file that was saved in a legacy encoding will upload to a platform, pass every validation check, and display as boxes to every viewer. Nothing in the workflow warns you, because the file is structurally valid. The only reliable check is to look at it in a real player before publishing.

Uploading an Urdu track to YouTube is the common case, and the Urdu subtitles for YouTube guide covers that path end to end.

Checking the rest of the file while you are there

Encoding is one of several faults that survive into a published file. Run the file through the subtitle validator to catch overlapping cues, backwards timing and unreadable reading speeds at the same time. If the captions are also out of sync, that is a separate problem covered in the out-of-sync subtitles guide.

When the source file is beyond saving, generate the captions again from the video in the AutoCaption caption generator, which writes UTF-8 exports so the script survives to the player.