Hard subtitles vs soft subtitles: burned in or a file?

Open the video in a player and look for a subtitle menu. If the menu lists a track you can switch off, the text is soft — it is being loaded from a file the player found. If the menu shows nothing at all and the text is still on screen, the text is hard — it is part of the picture.

A second test works without a player: rename the video file and open it again. A soft subtitle usually disappears, because the player was matching the subtitle file to the video by name. A hard subtitle never disappears, because there was never a separate file to lose.

The third test is the one that matters for archives. Run the video through a transcription tool. If the tool can read the text, the text exists as data somewhere. If the tool returns nothing, the text is pixels — which is exactly what happens with a hardcoded file produced from a subtitle track that was never kept.

The word "subtitle" describes the thing the viewer sees, not the thing the editor works with. That single overload produces most of the support questions in this field: someone says "the subtitles are wrong" when they mean the text is wrong, someone says "the subtitles do not work" when they mean their player cannot open an ASS file, and someone says "the subtitles are gone" when they mean they renamed a file.

The professional vocabulary separates the two: subtitling produces a track, and rendering produces a picture. A delivery spec usually names both, for example "deliver an MP4 with burned-in Chinese subtitles plus the SRT". When a spec names only one, ask which one, because the two are not interchangeable and the difference is not recoverable after the fact.

The distinction also explains why tools advertise different things. A transcription tool produces a track. A renderer produces frames. A product that does both has to keep the track, because the track is the only editable version of the work.

On a platform that accepts subtitle uploads, a soft file is an asset: the platform stores it as a track, offers it in the player menu, and — on the larger platforms — indexes the text so the video can be found by what is said in it. That indexing is usually the reason a soft file is worth the extra step.

On the same platform, a hard file is just video. The text is visible to people and invisible to the platform, so search inside the platform cannot surface the video by its spoken content. If discoverability matters, deliver the soft file as well; the two are not in competition, they are used by different systems.

There is a third case worth planning for: a platform that accepts neither an external file nor a burned copy, but has its own caption editor. In that case the soft file is still the useful artifact, because it can be pasted into the platform editor as text and re-timed there. A hard file gives you nothing to paste.

Burning text into frames is a one-way operation. Once the file is rendered, a wrong character is part of the picture: fixing it means fixing the track, re-rendering, and re-delivering. On a five-minute clip that is minutes of work; on a forty-minute lecture with three reviewers it becomes a scheduling problem.

The practical rule is to treat the subtitle file as the review artifact and the rendered video as the delivery artifact. Reviewers read the file, argue about wording, and approve a version. Only the approved version is rendered. This is the same discipline as locking a script before recording a voiceover.

There is one exception worth knowing: when the review has to happen in context — a joke that only lands with the timing, a sign on screen that the line refers to. In that case render a low-cost preview at low resolution, review it, then render the delivery copy from the approved file. Two renders, one of them cheap, is still cheaper than re-rendering a final.

A soft subtitle is drawn by the player, so the player decides the font, the size, and often the position, unless the file is an ASS file with explicit styling. A hard subtitle is drawn by you, so every one of those choices becomes a delivery decision that someone will judge.

The four decisions that cause most revisions are the vertical position (how far the text sits from the bottom edge, and whether that collides with platform UI or an existing burned caption), the size relative to the frame (a percentage of frame height, not a fixed pixel number, or the text will be wrong on a different resolution), the outline (a dark stroke is what makes text readable over a bright wall), and the safe margin (keep text out of the outer edges that some players crop).

For Chinese specifically there is a fifth: whether pinyin sits above the characters, and at what size ratio. A pinyin line at the same size as the hanzi fights for attention; a line at half the size reads as a gloss. If the pinyin is the point of the deliverable, the frame has to be composed with that in mind, because the text will cover part of the picture.

Deliver soft when the recipient is a player, a platform, an archive, a translator, or a colleague who might edit. Deliver hard when the recipient is a viewer with no subtitle support, a classroom projector, a client who will forward the file, or a social upload where the first three seconds decide whether anyone keeps watching.

Deliver both when the platform supports a track and the audience needs the text to be visible immediately. This is the common case for teaching material: the burned copy guarantees the text is seen, the soft file guarantees the text is searchable and editable later.

Do not deliver only hard when the work will be reused. A burned copy is a dead end for translation, for correction, and for the next cut. Keeping the track costs a few kilobytes and saves the whole job later.

SubChinese produces the track first: timed Chinese, character-aligned pinyin, and an optional meaning layer. The SRT export carries plain text and timing. The ASS export carries text, timing and positioning, which is what a player needs to draw pinyin above the characters.

Burned-in MP4 — the hard subtitle case — is rendered from that same approved track on the Studio plan, up to 60 minutes of finished video per month. The render happens on the file you upload, and the finished MP4 is what you get back; the source video is not kept in our storage afterwards. Only the subtitle work stays in the account, because that is the part you will want to edit.

We do not claim a burned copy is editable, and we do not offer to "extract" text from a video we did not process. If your text only exists inside pixels, the honest path is a fresh transcription pass, reviewed against the picture.