Subtitle preview that matches the final export

A convincing mock preview is not enough

Subtitle work often looks finished until the export arrives. A line wraps one word earlier. A background box changes size. A custom font falls back. A karaoke highlight advances differently. The editor did not necessarily make a bad styling decision; it approved a different renderer from the one that created the file.

That mismatch is expensive because it appears at the end of the workflow. The editor waits for a render, spots the drift, returns to the project, guesses at a compensation, and renders again.

CutCaption’s central promise is straightforward: what you preview is what you export. The high-fidelity browser preview and the burned video path meet at the generated ASS/libass representation instead of maintaining unrelated visual interpretations.

The shared render path

The project starts with canonical caption text, timing, and style data. CutCaption turns that state into an ASS subtitle track. That track feeds:

• JASSUB/libass for high-fidelity browser preview;
• ASS download on eligible plans;
• FFmpeg/libass when captions are burned into an exported video.

A lightweight CSS renderer can keep editing feedback responsive, but the libass view is the approval surface for output behavior. The goal is not a screenshot that resembles the export. It is one subtitle program interpreted by the same rendering family.

A parity-first review workflow

1. Correct the transcript and cue timing before doing detailed styling.
2. Establish the global font, size, outline, shadow, background, margins, and position.
3. Add local overrides and effects where the story needs them.
4. Save the caption state you intend to deliver.
5. Review long lines, scene changes, bright footage, and lower-third collisions in the libass preview.
6. Test fast active-word or karaoke sections at normal playback speed.
7. Export from that same saved state rather than rebuilding styles in another tool.

This sequence keeps corrections legible. If a cue is wrong, the editor can decide whether the source is text, timing, base style, local override, or effect logic without comparing two render engines at once.

What parity does and does not promise

The shared ASS/libass path covers subtitle layout and styling behavior: timing, wrapping rules, positioning, layers, overrides, and supported effects. It does not remove the need to check the complete media file.

A final exported-video review can still catch encoding damage, a cropped frame supplied by another system, or a font that is unavailable in an external ASS player. When the subtitle is burned into the video, the font is part of that render. When an ASS file is delivered separately, the playback environment still matters.

Review the cases most likely to drift

Do not spend the whole approval pass on easy, centered two-line captions. Check the edges:

• the longest caption in the project;
• a caption near a logo, lower third, or safe-area boundary;
• a line with a local position or rotation override;
• a cue with several inline styles;
• the fastest karaoke or active-word passage;
• a scene where contrast changes sharply.

For the rendering detail behind this workflow, see libass subtitle preview in the browser. If a client needs the editable styling recipe, see the online ASS subtitle workflow.