Every subtitle tool in this industry says it follows the Netflix style guide. In practice that phrase almost always means two things: 42 characters per line, maximum two lines. We shipped our subtitle module saying it too, and we were as guilty as anyone.
Then somebody asked the uncomfortable question — did we actually read all of it? So we did: five published documents, including a timing guide we had never opened, inventoried into 144 individual rules, each one checked against what our pipeline really does. Roughly a fifth of them we were not honouring. Here is what was missing, because the gaps are more interesting than the passes.
Shot changes, which we were ignoring entirely
A subtitle that starts a few frames before a cut, or lingers a few frames after one, reads as a glitch. The eye notices the cut, re-reads the line, and loses a second of the film. The guide has precise rules for this, and honouring them requires knowing where the cuts are — which means analysing the picture, not the audio.
We now detect scene changes from the video in parallel with transcription, so it costs no extra time. A cue that starts just before a cut is snapped to it; one that ends just after is pulled back to sit clear of it. The cuts also appear as amber marks on the waveform in the review editor, so a human retiming a cue by hand can see exactly what they are landing on.
Reading speed is not one number
We had a single characters-per-second limit. The guide does not: it varies by language and by audience, and adult English tolerates meaningfully more than adult Spanish, which tolerates more than anything aimed at children.
Now the limit is derived from the language of the track being read, and the translated track uses the target language's number — not the source's. This has a consequence worth stating plainly: Spanish captions are now measured against a stricter limit than before, so you will see more reading-speed warnings on Spanish jobs than you used to. They were always there. We were measuring with the wrong ruler.
The rest of the list
- Gaps between cues: two frames, or none at all — a gap under half a second is closed rather than left as a flicker, and out-times are extended into the silence that follows.
- Line balance: when a cue breaks into two lines, the bottom line carries the weight, and a break is never made after an article or a preposition.
- Two speakers in one moment: one cue with dashes, in the punctuation convention of the language, instead of two cues fighting for the same second.
- Italics, which subtitles use for a specific and narrow set of meanings — now settable per cue and carried into SRT and WebVTT correctly.
- Position: any cue can be moved to the top of the frame when the bottom is covered by burned-in text, and it stays there through burn-in.
- Ellipsis for a pause of two seconds or more, as the single character the guide asks for, not three periods.
- Number conventions, which are language-specific and unglamorous: when to spell a number out, when to use digits, what to do with ages and percentages.
- A glyph check that flags control characters, replacement characters and emoji — anything a caption player may render as a box in front of a viewer.
And SDH became its own thing
Subtitles for the deaf and hard of hearing are not captions with extra text bolted on; they follow different rules about speaker identification and non-speech sound. Trying to serve both from one configuration produces something that is wrong for both, so SDH is now a separate profile with its own behaviour, selectable when you order captions.
Why publish the gaps
Because the alternative is the industry norm: claim compliance with a document nobody on the team has read past page four. We would rather say that for a few weeks our subtitles honoured 42 characters and two lines and not much else, and that they now honour the timing rules too — including the ones that require looking at the picture.
None of this is configurable and none of it needs to be. It is what a subtitle job does now. If your distributor holds you to that guide, the output is built to survive their check.
Want this in your workflow? Try Fily with one file — no card, no demo form.
