Free online subtitle converter
Inspect and convert common timed-text subtitle formats in a browser worker without uploading the source file. Files are fully preflight-checked in a local worker before they become Ready; keep important source subtitles until you verify the converted copy.
0 files
Subtitle text stays local. Timing and readable dialogue are preserved where possible; ASS/SSA styling, karaoke, positioning, and effects are not carried into simpler outputs.
More than “change the extension and download.”
The Subtitle engine treats conversion as a timed-text workflow: it validates the complete file in a worker, exposes useful queue metadata, supports exact timing correction, lets you deliberately clean formatting, and offers flexible transcript export without sending the subtitle to a remote conversion service.
SRT, VTT, SBV, ASS, and SSA do not share the same presentation model. Rich metadata is detected before conversion and loss is stated explicitly instead of silently pretending everything survived.
The queue says Ready only after the whole subtitle parses.
Filename checks alone are not enough for subtitle files. Admission runs in the same local Web Worker used for conversion and parses the complete file before accepting it.
| Preflight check | What the user gets |
|---|---|
| Complete cue parse | Broken timing near the end of a file is caught before conversion starts. |
| SRT structure guard | Multiple timestamp lines inside one cue block are rejected instead of becoming silent subtitle text. |
| Cue count | The queue metadata shows how many timed cues were detected. |
| Timeline end | A quick duration sanity check appears beside the source format. |
| Text encoding | UTF-8, UTF-16LE, UTF-16BE, or Windows-1252 fallback is reported. |
| Rich metadata flag | ASS/SSA formatting and WebVTT metadata are surfaced before simpler output is chosen. |
Useful subtitle transforms, still simple enough for a converter.
The goal is not to recreate a full subtitle editor. The controls focus on common conversion problems that are safe to apply consistently across a batch.
| Control | Behavior | Safety rule |
|---|---|---|
| Timing shift | Enter an exact -600000 to +600000 millisecond offset. | A negative shift that would put any cue before 00:00 fails instead of clipping silently; out-of-range values fail clearly. |
| Plain text only | Remove inline cue markup from SRT/VTT/SBV output. | Off by default so normal timed-text formatting is not unexpectedly stripped. |
| TXT timestamps | Choose none, start time, or start → end range. | TXT always removes markup because it is a transcript-like output. |
| Cue spacing | Blank-line or single-line separation for TXT. | Source cue order is never reordered or merged. |
| LF / CRLF + BOM | Control output bytes for downstream tools. | Output text is always UTF-8. |
Same-format VTT cleanup no longer throws away document metadata by default.
When a VTT file is exported as VTT without a timing shift or formatting cleanup, the converter validates the document but preserves the original WebVTT body, including document-level STYLE, REGION, NOTE, X-TIMESTAMP-MAP, cue IDs, and cue settings. Line endings and BOM can still be normalized.
If timing or text is transformed, the file is intentionally rebuilt from parsed cues. At that point richer document-level VTT metadata cannot be guaranteed and the source should be kept.
What survives depends on the destination.
- SRT cue numbers are regenerated deterministically while cue order and timing are kept.
- WebVTT cue identifiers and settings can be represented in VTT, but simpler outputs cannot carry VTT regions or STYLE blocks.
- ASS/SSA Dialogue timing and readable text are extracted while styles, karaoke, positioning, effects, drawing commands, and override tags are removed in simpler outputs.
- SBV timestamps are converted without reordering cues.
- TXT is always plain readable text and can optionally carry timing context.
Handle common subtitle text without hiding what was detected.
The converter recognizes UTF-8, UTF-16LE, and UTF-16BE byte-order marks. Without a BOM it attempts strict UTF-8 first and then Windows-1252 for common legacy subtitle exports. The detected encoding is shown in queue metadata after full-file preflight.
Renaming arbitrary text to .srt or .vtt is not enough. The full subtitle structure has to parse before the file becomes Ready.
Every published pair is backed by the same tested engine.
SRT, VTT, ASS, SSA, and SBV are expanded only into destinations that the converter can really write: SRT, VTT, SBV, and TXT. Same-format SEO pages are intentionally not created.
Learn the format decision before you convert.
Use these guides when the problem is compatibility, timing, styling, transcript export, or text encoding rather than the conversion button itself.
Small text files still get explicit browser safety boundaries.
The converter uses a 5 MB per-file ceiling, 50 MB total batch input, a maximum of 50 files, worker timeouts, a ±600000 ms timing-offset boundary, and a 100,000-cue parser guard. Full-file preflight also prevents partially valid subtitles from entering the ready queue.
No OCR, speech-to-text, subtitle translation, frame-rate retiming, automatic audio/video synchronization, ASS/SSA style preservation, or video embedding. This remains a deterministic timed-text converter, not a media editor.
Subtitle conversion questions
Answers about preflight parsing, exact timing correction, SRT, WebVTT metadata, ASS/SSA styling, SBV, transcript export, encodings, local processing, and browser limits.
Which subtitle formats can I add?
The Subtitle Converter accepts SRT, VTT/WebVTT, ASS, SSA, and SBV. Before a file becomes Ready, the complete subtitle is parsed in a local worker so malformed later cues are caught during admission rather than after conversion starts.
Which subtitle formats can I export?
Supported outputs are SRT, VTT, SBV, and plain TXT. The public catalog exposes 17 useful cross-format routes. ASS and SSA remain input-only because their richer styling, positioning, karaoke, and effect model cannot be recreated faithfully by the simpler outputs.
What does the preflight analysis show?
Accepted files report cue count, timeline end, detected text encoding, and a flag when richer formatting or WebVTT metadata is present. This is calculated locally from the full file before it enters the ready queue.
Can I shift subtitle timing precisely?
Yes. Timing shift accepts an exact millisecond offset from -600000 to +600000 ms, so values such as +1350 or -780 work across the whole batch. If a negative shift would move any cue before 00:00, conversion fails instead of silently clipping the timestamp.
Can I remove subtitle formatting?
For SRT, VTT, and SBV output you can enable Plain text only to remove inline formatting from cue text. TXT output is always plain readable text and removes subtitle markup automatically.
What TXT transcript options are available?
TXT can export dialogue with no timestamps, each cue start time, or complete start-to-end ranges. Cue spacing can use a blank line or a single line break, and LF/CRLF plus optional UTF-8 BOM are available for downstream compatibility.
Are my subtitle files uploaded?
No. Preflight analysis, parsing, timing transforms, text cleanup, and serialization run inside a browser worker. The selected subtitle is not sent to a ConvertAnyFile conversion server.
What happens to ASS or SSA styling?
Dialogue start time, end time, and readable text are carried into the target. ASS/SSA override tags, named styles, fonts, colors, positioning, karaoke instructions, drawing commands, and effects are intentionally not preserved in SRT, VTT, SBV, or TXT output.
What happens to WebVTT metadata?
SRT, SBV, and TXT cannot represent WebVTT STYLE, REGION, NOTE, X-TIMESTAMP-MAP, cue positioning, or other VTT-only metadata. A no-transform VTT-to-VTT export preserves the original validated WebVTT body by default; applying timing or text transforms rebuilds cues and cannot guarantee document-level metadata preservation.
Which text encodings are supported?
UTF-8 is preferred. UTF-8, UTF-16LE, and UTF-16BE BOMs are recognized. Files without a BOM are decoded as strict UTF-8 first, with Windows-1252 as a compatibility fallback. The detected encoding is shown in queue metadata; generated text output is UTF-8.
Why does the Subtitle converter have file-size limits?
Subtitle conversion is lightweight, but complete preflight parsing and unexpectedly large timed-text files can still consume browser memory and CPU. Current limits are 50 files, 5 MB per file, 50 MB total input, and a 100,000-cue parser guard.