SMI to SRT
Or paste subtitle text
What this conversion changes
3 things are dropped or need a decision
- Styling
all styling (bold, italic, colour, outline, shadow)
- Positioning
on-screen positioning (every cue returns to the default position)
- Format-specific content
content the source format keeps outside its cues (non-cue blocks, header text, per-cue settings, commented-out events) — the target format has no place for it
This list comes from the capability matrix for these two formats, not from the particular file you loaded. A specific file may lose more if it uses features the format allows but the matrix does not model.
This page converts SMI to SRT. Drop a file in — or paste the text — and you get the SRT version back. The conversion runs entirely in your browser, so nothing is uploaded and no account is needed.
These two formats do not store the same things, and the difference is not cosmetic: styling, positioning and format-specific content have nowhere to go in SRT. The list above comes from what the two formats can each express rather than from your file, so it is the same answer before you load anything.
One file is fine, and so is a whole season: the queue works through them in order and the results come down together as a single ZIP.
Examples
A typical SMI file, converted to SRT
Input
<SAMI>
<HEAD>
<STYLE TYPE="text/css">
<!--
P { text-align: center; font-family: Arial; }
.ENCC { Name: English; lang: en-US; }
-->
</STYLE>
</HEAD>
<BODY>
<SYNC Start=1000>
<P Class=ENCC>Hello there.
<SYNC Start=3000>
<P Class=ENCC>
<SYNC Start=3500>
<P Class=ENCC>How are you?<br>Fine, thanks.
<SYNC Start=6000>
<P Class=ENCC>
</BODY>
</SAMI>
Output
1
00:00:01,000 --> 00:00:03,000
Hello there.
2
00:00:03,500 --> 00:00:06,000
How are you?
Fine, thanks.
Dropped in this output: styling, positioning and format-specific content. Everything else matches line for line.
The same conversion on an awkward input
Input
<SAMI>
<HEAD>
<TITLE>Episode 1</TITLE>
<STYLE TYPE="text/css">
<!--
.ENCC { Name: English; }
-->
</STYLE>
</HEAD>
<BODY>
<sync start="00:00:02,500">
<P Class=ENCC>Line one<br>Line two
<sync start=9000>
<P Class=ENCC>Tom & Jerry
<SYNC Start=12000>
<P Class=ENCC>
</BODY>
</SAMI>
Output
1
00:00:02,500 --> 00:00:09,000
Line one
Line two
2
00:00:09,000 --> 00:00:12,000
Tom & Jerry
This is the kind of damage real files have — mixed line endings, stray whitespace, fields left empty. Compare it with the tidy example above to see what the parser forgives.
Frequently asked questions
Do bold and italic survive from SMI into SRT?
Emphasis does; the style table does not. Formatting that belongs to a piece of text — bold, italic, underline, a colour — is written into the SRT text as tags (`<i>`, `<b>`, `<u>`, `<font color="…">`), because that is the one kind of styling a cue-level format can still carry. What is lost is everything the SMI file said globally: the font, its size, the outline, the shadow and the margins.
What happens to the on-screen position from SMI to SRT?
SRT cannot say where a subtitle is drawn, so the paragraph attributes and the CSS they point at are dropped on the way out of SMI, and every cue goes back to the default position the player chooses — the bottom of the frame, centred, for most of them.
What happens to SAMI's `<STYLE>` block, `<TITLE>` and `Class=` attributes in SRT?
They are dropped. SAMI says what its subtitles look like outside the text of the cue: a `<STYLE>` block of CSS for the paragraphs, a `<TITLE>`, and the channel marker each paragraph carries — `Class=ENCC`, which points at one of those rules. SRT stores cues rather than a document, so there is nowhere for any of that to go. Emphasis written inside a cue's own text is unaffected — that belongs to the line — and the cues come through with their text and timings whole.
What does the output look like when SMI becomes SRT?
Like SRT: a number above every timecode, counting from 1. Every SMI cue becomes one SRT cue, in the same order, with the same text.
Are the SMI timings exact in the SRT file?
Yes, to the millisecond — which is as fine as either format goes. SMI writes a moment as `Start=4126` and SRT writes the same moment as `00:00:04,126`; nothing is rounded or shifted between the two, and a cue that was on screen for 2.9 seconds still is.
How does a two-line SMI cue come out in SRT?
As two lines, one under the other. The pairing survives — the two SMI lines still belong to one subtitle in the SRT output, and a player shows them together.
Do SMI cues keep their order in the SRT output?
Yes, and they are sorted by start time on the way — earliest first, which is how every format here expects them and how players read them. If your SMI file listed its cues out of sequence, the SRT output puts them back in order; that is a change to the file's structure rather than its content, and it is deliberate.
Can I convert the SRT back to SMI?
Yes, and that direction costs nothing: an SRT file holds less than SMI can, so nothing further is dropped on the way back. What this direction dropped stays dropped, though — styling, positioning and format-specific content cannot be rebuilt from an SRT file, because nothing in it records what they were.
Does the SRT output keep the SMI file's encoding?
No — the output is UTF-8, with Unix line endings and no byte-order mark, whatever the SMI file used. A file that arrives in UTF-16, or in a Windows single-byte encoding, is decoded on the way in (the result panel says so when that happens); what comes out is always the same UTF-8 SRT.