Question marks and boxes in VLC subtitles are two different faults with two different fixes. Question marks mean the selected text encoding is wrong. Boxes mean the selected font does not contain the characters your subtitle file is asking for. Almost every guide on this topic treats them as one problem and sends you to the same encoding dropdown — and that dropdown will never fix boxes.
VideoLAN says this itself, on the page it keeps for exactly this symptom. That page belongs to what VideoLAN calls the VLC Support Guide, which the project describes in its own words as "an informal, step-by-step guide for troubleshooting most common issues with VLC" — hosted and linked by VideoLAN, but not part of the formal documentation set.
What VLC is actually telling you
The support guide's rendering page is two short paragraphs, and they draw the line cleanly.
On question marks:
"If you see question marks or weird characters, this means that the selected encoding is wrong. Change it in preferences, in the OSD section."
On boxes:
"If you see boxes or squares, it means the selected font lacks the needed characters. Change the font in preferences, in the OSD section."
Same settings section, different setting, different cause. The first symptom is about which characters VLC believes are in your file; the second is about whether the font you picked can draw them. VideoLAN assigns each symptom its own fix, so the usual advice — reach for the encoding dropdown whatever you are seeing — is aimed at the wrong layer half the time.
Fix 1: question marks or weird characters
VideoLAN's HowTo for this gives the menu path and one instruction people skip:
"Select Tools → Preferences."
"Select Subtitles / OSD → Default encoding."
And then, verbatim:
"If you see wrong characters on screen or failed to convert subtitle encoding error message you should try to change Subtitles text encoding option. Remember to press Save to save VLC settings and restart VLC after that to make sure changes are enabled."
Two things there. failed to convert subtitle encoding is a real VLC message and lands you in the same place as visible garbling — same cause, same fix. And press Save and restart VLC; VideoLAN spells that step out rather than assuming it.
Why a correct file should not need this at all
A vlc -H dump published on VideoLAN's wiki, taken from a vlc-4.0.0-dev build on Windows, documents a setting that changes how you should think about this:
"--subsdec-autodetect-utf8, --no-subsdec-autodetect-utf8 UTF-8 subtitle autodetection (default enabled) This enables automatic detection of UTF-8 encoding within subtitle files."
In that 4.0.0-dev output, UTF-8 autodetection is listed as enabled by default. A file genuinely saved as UTF-8 should therefore render correctly with no configuration at all, so question marks strongly imply the file is not UTF-8 — it came out of whatever produced it in some legacy encoding. That leaves two routes: tell VLC which legacy encoding to assume, or re-save the file as UTF-8 and stop carrying the problem from player to player.
The encoding list, and why guessing is the slow path
If you go the first route, the dropdown is long. That same vlc-4.0.0-dev dump lists the accepted values as:
"
--subsdec-encoding={,system,UTF-8,UTF-16,UTF-16BE,UTF-16LE,GB18030,ISO-8859-15,Windows-1252,IBM850,ISO-8859-2,Windows-1250,ISO-8859-3,ISO-8859-10,Windows-1251,KOI8-R,KOI8-U,ISO-8859-6,Windows-1256,ISO-8859-7,Windows-1253,ISO-8859-8,Windows-1255,ISO-8859-9,Windows-1254,ISO-8859-11,Windows-874,ISO-8859-13,Windows-1257,ISO-8859-14,ISO-8859-16,ISO-2022-CN-EXT,EUC-CN,ISO-2022-JP-2,EUC-JP,Shift_JIS,CP949,ISO-2022-KR,Big5,ISO-2022-TW,Big5-HKSCS,VISCII,Windows-1258}"
Note the shape of it: four Unicode entries, roughly three dozen legacy ones, and a blank first entry plus system, whose behaviour the documentation does not explain. Working through those one at a time, restarting VLC after each, is a bad afternoon.
The decisive move is to normalise the file to UTF-8 once, instead of working down that list by trial.
Try it right here
Runs in your browser. Your file is not uploaded anywhere.
It runs in your browser — the file is read and rewritten locally, never uploaded — reading input as UTF-8 and writing UTF-8 output. That makes it a test as well as a conversion: if the result looks mangled, your source was not UTF-8, which confirms the diagnosis before you change a single VLC setting. For the reverse direction, VTT to SRT works the same way.
One caveat on the output format: VideoLAN's documentation is inconsistent about WebVTT. The --sub-type list of text subtitle parsers omits it, the encoder enumeration does list webvtt, and the official subtitle support table has no WebVTT row. Across those three, the documentation does not state clearly whether VLC supports WebVTT subtitles — check the official documentation for your build rather than assuming either way. The same table does list SubRip as supported. Both formats are compared in SRT vs VTT.
Fix 2: boxes or squares
Boxes are a font problem, so the encoding dropdown is the wrong screen. VideoLAN's HowTo for font settings gives the path, plus a conflict worth knowing about:
"Go to Tools → Preferences (set Show Settings to All) and Video → Subtitles/OSD → Text renderer and adjust anything you want. Font size in pixels overrides Relative font size selection."
Pick a font that contains the script your subtitles are written in. That is the whole fix — the missing piece is coverage, not size or colour.
The official User Guide adds the step that catches people out after they change it:
"You need to restart your stream for the font modifications to take effect."
Where this fix simply does not apply
This is the boundary nobody mentions, and it explains the "I changed the font and nothing happened" cases. VideoLAN states it directly:
"The font settings can be adjusted for plain text subtitle formats. Font settings cannot be changed for rich text (e.g. ASS) or bitmap (e.g. DVD) subtitle formats."
So ASS/SSA subtitles ignore your font setting, and DVD-style subtitles are not text at all. The User Guide is explicit about the image-based ones:
"DVD and SVCD subtitles are merely images, so you won't be able to change anything for them. OGM and Matroska subtitles are rendered text, so you will be able to change several options."
VobSub gets its own warning in the same document:
"Encoding, alignment and size won't have any effect for Vobsub subtitles."
If your subtitles come from a DVD rip or a .sub/.idx pair, neither fix on this page applies — you are looking at pictures of letters, with no text being decoded and no font being chosen. (The same page also notes that for VobSub you must select the .idx file, not the .sub file.)
How to tell it worked
Restart VLC after an encoding change and reopen the video — the guide that gives the menu path asks for the restart explicitly, to make sure the change is enabled. For a font change, restart the stream.
Then jump to a line that was visibly broken rather than judging by the first caption: plain unaccented text looks fine under either fault. If what you are still looking at is boxes or squares rather than question marks, encoding was never the lever — go do Fix 2.
FAQ
Why do my VLC subtitles show question marks?
Because the selected text encoding is wrong — VideoLAN's support guide says question marks or weird characters mean exactly that, and points you at preferences, in the OSD section. Since UTF-8 subtitle autodetection is listed as enabled by default in the vlc -H output published for a vlc-4.0.0-dev build on Windows, it usually means the file was not saved as UTF-8.
Why are my subtitles showing as boxes or squares? Because the selected font lacks the needed characters, per the same page. This is a font-coverage problem, not an encoding problem, and changing the encoding will not fix it. Change the font under Video → Subtitles/OSD → Text renderer instead.
Where is the subtitle encoding setting in VLC? Tools → Preferences, then Subtitles / OSD → Default encoding. Press Save and restart VLC afterwards — VideoLAN's HowTo says to do this to make sure the change is enabled.
I changed the encoding and nothing happened. What now? Three possibilities, in order: you did not press Save and restart VLC; you have the boxes symptom rather than question marks, so encoding was never the right lever; or your subtitles are image-based, and VideoLAN says encoding, alignment and size have no effect for VobSub subtitles.
Can I change the font for ASS subtitles? No. The font settings apply to plain text subtitle formats, and VideoLAN states they cannot be changed for rich text such as ASS or bitmap formats such as DVD. If ASS subtitles look wrong rather than missing, the support guide points at the libass plugin — it says support is better in VLC media player 1.1.9 or over, and to check that the libass plugin is present.
Is this the same problem as subtitles not showing up at all? No — that is a loading or track-selection issue, not a rendering one. Encoding and font faults mean VLC found your file and is drawing it, just drawing the wrong thing. For the missing-entirely case see VLC subtitles not showing; if they appear but land at the wrong moment, that is subtitle delay instead.
Fix the file once and the problem stops following you between players. More player and export fixes live in the fix guides, and every browser-local converter we run is listed on all Clapr tools.
Quotes above are from VideoLAN's own documentation and support-guide pages, checked 16 September 2026. The support guide is self-described as informal, and the vlc -H output quoted is from a vlc-4.0.0-dev build — run vlc -H to see exactly what your build exposes.
