Turn SUB subtitle files into CSV for easier editing, reviewing, and importing into spreadsheets—fast conversion directly in your browser.
Converting a .sub file to CSV is not really a format conversion — it is a workflow move. Subtitle formats are optimised for a player to read; a spreadsheet is optimised for a person to read, sort, count, translate and comment on. This tutorial covers the round trip: what the three columns contain, how the escaping works so your dialogue survives commas and quotes, the one thing to watch when you add a translation column, and the frame-rate question that decides whether the Start and End values mean anything at all.
{start}{end}text lines into the Input (SUB) box. The character count beside the label confirms it was read; the picker takes one file at a time.{1}{1}23.976. This parser reads every MicroDVD file at 25 fps and has no frame-rate control, so anything else means the Start and End columns need verifying — delete that line before converting either way.subtitles.csv, or "📋 Copy" to paste the rows straight into a sheet.The output is a three-column CSV with a header row. Times are written in SubRip style — a comma before the milliseconds — which means every timestamp contains a comma and is therefore always quoted:
Start,End,Text
"00:00:01,000","00:00:04,000",The quick brown fox
"00:00:04,000","00:00:07,000","He said ""hi"", then left"
| Column | Contents | Notes |
|---|---|---|
Start |
hh:mm:ss,mmm |
Always quoted, because the millisecond separator is a comma |
End |
hh:mm:ss,mmm |
Same; hours are a real field, so a cue at 61 minutes reads 01:01:40,000 |
Text |
The cue's dialogue | Quoted only when it contains a comma, a quote mark or a line break |
The escaping follows the usual CSV convention: a field containing a comma, a double quote or a newline is wrapped in quotes, and any double quote inside it is written twice. A cue reading He said "hi", then left becomes "He said ""hi"", then left", which is what a spreadsheet expects and reads back as the original string.
Multi-line cues are preserved rather than flattened. MicroDVD marks a line break with a pipe, and the converter turns it into a real newline held inside the quoted field — so the cell contains two lines, exactly as the subtitle did. That is the right behaviour for editing, and it is worth knowing about if you plan to process the file with a script, since a naive line-by-line reader will split those cells in half.
One practical note on opening the file: the download carries no byte-order mark. Most spreadsheet applications read UTF-8 correctly without one, but if accented or CJK text arrives as mojibake, use your application's text-import option and choose UTF-8 explicitly rather than double-clicking the file.
The point of the round trip is usually translation, QC or timing review, so the file needs to go back. Set "From format" to CSV and "To format" to whatever you need — SRT, VTT, ASS — and the reader will take it, with three rules worth knowing:
Start,End,Text header in place is the safe option.Start,End,Text,Translation produces cues reading Hello, Bonjour. If you are translating, delete or move the original-language column before converting back, or keep the translation in a separate file.{25}{100}Hello means frames 25 to 100. What that is in clock time depends entirely on the video the file was cut against, and MicroDVD's syntax has nowhere to record it. The convention is to write the rate as a first cue, {1}{1}23.976: FFmpeg's MicroDVD demuxer scans the opening lines looking for exactly that, and the reference Python library pysubs2 raises UnknownFPSError and refuses the file rather than guess when it is absent.
This converter does not read the hint line and has no frame-rate control, so every MicroDVD file is parsed at 25 fps. Delete the hint line before converting — otherwise it becomes a data row whose Text cell is 23.976 — and treat the Start and End columns as provisional until you have checked them against the video. A spreadsheet is a good place to do that check: sort by Start, look at the last row, and see whether it matches where the final line actually falls.
Frame number divided by frame rate is the time in seconds, so the arithmetic is easy to verify by hand:
| Frame number | at 23.976 fps | at 24 fps | at 25 fps | at 29.97 fps | at 30 fps |
|---|---|---|---|---|---|
| 24 | 0:00:01.001 | 0:00:01.000 | 0:00:00.960 | 0:00:00.801 | 0:00:00.800 |
| 1,500 | 0:01:02.563 | 0:01:02.500 | 0:01:00.000 | 0:00:50.050 | 0:00:50.000 |
| 90,000 | 1:02:33.754 | 1:02:30.000 | 1:00:00.000 | 0:50:03.003 | 0:50:00.000 |
The error from a wrong frame rate is proportional, not constant, so it survives a spot check on the opening minute and shows up at the end of the file:
| Source authored at | Read at 25 fps, cues land | After 1 minute | After 10 minutes | After 1 hour |
|---|---|---|---|---|
| 23.976 fps | early | 2.5 s early | 24.6 s early | 2 min 28 s early |
| 24 fps | early | 2.4 s early | 24.0 s early | 2 min 24 s early |
| 29.97 fps | late | 11.9 s late | 1 min 59 s late | 11 min 56 s late |
| 30 fps | late | 12.0 s late | 2 min 0 s late | 12 min 0 s late |
{digits}{digits} followed by text. A .sub that is really VobSub (binary subtitle bitmaps paired with an .idx) or SubViewer (already timestamped) produces no matches. Nothing was uploaded and nothing was lost; set "From format" to what the file actually is..sub makes line one unmatchable, because the cue pattern is anchored to an opening {. Windows-authored files often carry one; re-save without it, or paste the text into the input box instead of uploading.{1234}{} never appears — an empty end frame is accepted by some MicroDVD readers but not by this parser, which needs digits in both braces.23.976 — that is the frame-rate hint line converted into a data row. Delete it and note the number.< and a > on the same line is treated as markup and stripped, so 5 < 6 but 7 > 2 arrives as 5 2.Because the times are written in SubRip's format, hh:mm:ss,mmm, which is what every subtitle tool recognises and what makes the file convertible back into SRT without a reformatting step. The comma does not break the CSV, because both time columns are always quoted — a parser reads "00:00:01,000" as a single field. If you would rather have a dot, a find-and-replace inside the quoted columns is safe once the file is in a spreadsheet.
Yes, and it is one of the better reasons to convert a subtitle file to CSV — you get the source text in rows with its timings beside it, which is exactly what a translator needs for line-length and reading-speed decisions. The one trap is on the way back: the CSV reader joins column three and everything after it into the cue text, so a Start,End,Text,Translation layout produces cues reading original, translation. Delete the source column before converting back, or keep the translated text in its own three-column file.
The line break is preserved inside a quoted field, so the cell contains a real two-line value. MicroDVD writes those breaks as a pipe character, and the converter turns each pipe into a newline. Spreadsheets display that as a wrapped cell; scripts that read the file line by line will mis-split it unless they use a proper CSV parser.
No. MicroDVD's inline codes — {y:i} italic, {y:b} bold, {y:u} underline, {c:$BBGGRR} colour, {f:name} font, {s:n} size — are stripped during parsing, and the CSV has only a plain-text column to put them in anyway. If styling is what you care about, SUB to ASS gives you a real style table to edit instead.
They are written to the millisecond, which is finer than the source justifies. A MicroDVD frame is a 40 ms bucket at 25 fps, so the values are precise to a millisecond but only ever as accurate as the frame boundary the original author picked — and only as accurate as the frame-rate assumption described above. Do not read three decimal places as three decimal places of truth.
No, and that is the point. There is no standard for representing subtitles as CSV, no player reads one, and the column layout here is this tool's own convention rather than something you can hand to another application and expect it to understand. Use it as an intermediate step — read, edit, count, translate — and convert back to a real subtitle format before the file goes anywhere near a video.
We ran a MicroDVD file containing a cue with an embedded quote and comma, and a second cue using the pipe separator, through this exact pipeline. The output was a Start,End,Text header followed by one row per cue, both time columns quoted, the quote-and-comma cue rendered as "He said ""hi"", then left", and the piped cue held as a genuine two-line quoted field. Re-reading that CSV back through the converter returned the original text unchanged. The timings are the part to verify yourself.
No. The file is read in the browser with the FileReader API, converted by JavaScript that arrived with the page, and returned as a Blob download — no request carries your subtitle text off the machine, and there is no server-side copy to expire. If you need a player-ready file rather than a spreadsheet, SUB to SRT is the most widely supported target and the SUB converter hub lists the rest.