A client sent me a two-hour recorded interview and asked for subtitles. I said yes in about four seconds — then realised the transcription was the easy part. Subtitle delivery, it turns out, is the hard part. The hard part was everything after: six different deliverables, two formats the editor needed, timestamps that had to survive a re-edit, and a deadline that did not move.
Every article about subtitle tools stops at the transcript. That is the part that takes nine minutes. The part that eats your afternoon is subtitle delivery — deciding between hard and soft subtitles, keeping timestamps locked, exporting the right file for each platform, and batch-processing a whole series without hand-checking every single one.
This is the exact subtitle delivery workflow I run after transcription finishes: how I turn one raw transcript into platform-ready subtitle files in six formats, how I decide between burned-in and sidecar subtitles, and where a local tool like ClipScribe Pro fits instead of a per-minute cloud service.
Why subtitle delivery is the real bottleneck
Transcription tools have converged. Almost anything will give you a decent transcript of a clean audio track in minutes. What has not converged is the last mile: the client never wants “a transcript.” They want a burned-in MP4 for Instagram, an SRT for YouTube, a VTT for the web player, and a plain transcript for the blog — from the same source file, all in sync.
The formats themselves are standardised — the WebVTT spec from the W3C and the classic SubRip format are both public, so any tool you pick should speak them. The cost of getting this wrong is not aesthetic. A subtitle file with drifted timestamps fails QC silently: it plays fine for thirty seconds and then slides out of sync by a second per minute. A hard-subtitle burn that used the wrong font size fails review on a phone. A sidecar file delivered alone, when the platform needed burned-in text, means the client sees no captions at all.
Those are three different failure modes for the same task. That is why I treat delivery as its own workflow with its own checklist, not as a “save as” step at the end.
The six subtitle formats you actually get asked for
Before touching any export button, know what the destination expects. In practice I ship six formats across client work:
- SRT (.srt) — the universal sidecar. YouTube, most NLEs and most players import it. Text plus start/end timecode, nothing else.
- VTT (.vtt) — the web standard, required for HTML5
<track>elements. Adds cue settings like position and alignment. See the W3C WebVTT specification for the full cue syntax. - ASS / SSA (.ass) — styled subtitles with fonts, colours and positioning. This is what you burn in when you want branding or karaoke-style highlights.
- Burned-in MP4 — subtitles rendered permanently into the video pixels. Uneditable, un-loseable, works everywhere including muted autoplay feeds.
- Plain transcript (.txt / .md) — for SEO, blog repurposing and accessibility statements.
- Timestamped transcript (.txt with timecodes) — for editors who cut against the transcript instead of watching the whole thing.
One source transcript should produce all six formats. In a good subtitle delivery pipeline, if your tool makes you re-run transcription for each format, you are paying the transcription cost six times over.
Hard subtitles vs soft subtitles: how I decide
Subtitle delivery forces one decision clients actually argue about, and it has a clean rule.
Soft subtitles are a separate file (SRT/VTT) the player overlays on top of the video. They stay editable, stay searchable, can be translated and re-timed later, and do not bloat the video file. They are the right default for anything a client might revise — YouTube uploads, course platforms, corporate training.
Hard subtitles are burned into the pixels. They cannot be turned off, cannot desync, and cannot be misplaced by a platform that “forgot” to load the sidecar. They are the right choice for social cuts: muted autoplay, vertical reels, and anywhere the viewer scrolls past in three seconds.
My rule, in one line: if the video will be re-edited or republished, ship soft; if it is a final social cut, ship hard — and when in doubt, ship both. Because the source transcript is the same, producing both is a two-minute export, not a second project.
Keeping timestamps locked through re-edits
The single most common delivery complaint is drift: the client trims the intro, and suddenly every subtitle is early by eleven seconds. The fix is to export a timestamped transcript alongside the subtitle files, so anyone who re-cuts the video can re-time against a known reference instead of eyeballing it.
Two practices remove almost all drift reports:
- Export timestamps at frame-accurate or at least millisecond precision, not rounded seconds. Rounded seconds accumulate error across a two-hour file.
- Keep one canonical master file — usually the plain transcript with timecodes — and regenerate every subtitle format from it. Never hand-edit an SRT and then try to reconcile it with the VTT later.
When a client “fixes” a subtitle file by hand and you later regenerate, you silently overwrite their edit. That is a conversation you want to have up front: either they own the final file, or you own regeneration — not both.
Batch subtitle delivery for a whole series
Single videos are fine. Series are where a subtitle delivery workflow pays off. If a client sends ten episodes, doing the delivery step once per file is fifty manual export dialogs and fifty chances to misname a file.
What I do instead is batch subtitle delivery for the whole set in one pass with a predictable naming convention:
ep{NN}_{slug}.{srt,vtt,ass,mp4,txt}
One job, one folder, every episode and every format named the same way. The client gets a folder they can hand to an editor without a README. Scripted naming is boring and that is exactly the point — it removes the human step where files get mixed up.
Batching is also where local processing beats per-minute billing. Ten two-hour episodes is twenty hours of audio; a per-minute cloud service meters every one of those hours, every time you re-export. A tool licensed once does not count the minutes.
Where ClipScribe Pro fits
I run this subtitle delivery pipeline with ClipScribe Pro, an offline subtitle tool that covers the whole arc rather than just the transcript. Whisper-based transcription in 99+ languages, scene detection and chapter markers so long files are navigable, and hard or soft subtitle export in the formats above — all processed on the machine, nothing uploaded.
The reason it wins for client work is not raw transcription speed — plenty of tools are fast. It is that the delivery step is native: I pick a source, set the output formats once, and get SRT, VTT, ASS, burned-in MP4 and a timestamped transcript from a single run, batch-style across episodes. No per-minute meter, no uploading confidential interview footage to a third party, no re-running transcription because the client wanted a different container.
Platform subtitle requirements are worth checking before you export: YouTube’s caption guidance and the W3C accessibility guidance on captions both shape what clients expect. If your recordings are confidential — legal interviews, internal training, medical or financial conversations — “nothing leaves the laptop” is not a nice-to-have. It is the requirement that rules out most cloud subtitle services before you compare features.
FAQ
Can I convert an existing SRT to hard subtitles without re-transcribing?
Yes. Import the SRT, map the styling once, and burn it in. Re-transcribing to change the container is wasted work — the transcript is already correct.
SRT or VTT for YouTube?
YouTube accepts both; SRT is the safer default for older pipelines, VTT if you need positioning. Upload the sidecar, not a burned copy, so captions stay toggleable and indexable.
How do I stop subtitles from desyncing after an edit?
Keep one canonical timestamped transcript and regenerate every format from it. Export at millisecond precision so rounding error cannot accumulate over a long file.
Is burned-in subtitles bad for SEO?
Burn-ins do nothing for search because the text is pixels. That is why you ship the sidecar and the plain transcript alongside the video — the caption file is what gets indexed.
Do I need a cloud service for batch subtitle delivery?
No. Batch export is a file-format operation; it runs locally on the same machine that transcribed the audio, which also keeps client footage private.
The bottom line
Transcription is a solved problem and a fast one. The value you actually sell to a client is subtitle delivery: the right format, the right timing, the right file names, every time, across a whole series. Build that last-mile checklist once — hard versus soft, six formats from one source, frame-accurate timestamps, scripted naming — and the work gets dramatically less error-prone.
ClipScribe Pro keeps subtitle delivery inside the same offline tool that does the transcription, in 99+ languages, without a per-minute meter. That is how a two-hour interview stops being an afternoon of export dialogs and becomes a nine-minute job with a clean handoff folder.
Put this into practice: take one video you already transcribed, export it as a full subtitle delivery set (SRT, VTT and a burned-in MP4) in a single pass, and hand the folder to someone. If they can use it without asking you a single question, your delivery workflow is finished.
Disclosure: this article contains affiliate links. If you buy through them, I may earn a commission at no extra cost to you. I only recommend tools I use in my own workflow.
