Subtitle Styling Guidelines for Production Teams

Good subtitle styling comes down to a short list of decisions: a plain sans-serif font, white text on a dark band, no more than two lines of about 42 characters, a reading speed of 15 to 20 characters per second, and a file format that keeps your styling alive. This guide gives you the numbers, explains the reasoning, and then shows how to turn them into a written spec your client can accept or reject without argument.

TL;DR

• Use a legible sans-serif such as Arial, Roboto or Open Sans, white text, and a semi-transparent dark band. On 1080p video, keep text at 46px or larger.
• Limit each subtitle to two lines and roughly 42 characters per line, and cap reading speed at 15 to 20 characters per second.
• Pick the format first. SRT strips styling, WebVTT supports basic web styling, and TTML or IMSC carries the precise styling streamers require.
• Style the words as well as the pixels: keep a glossary of names and terms so they read the same in every episode.
• Write the rules into the project intake and turn them into acceptance criteria, so approval is a checklist instead of an opinion.

Table of Contents

• The visual basics: font, size, color and background
• Line length, line breaks and reading speed
• Placement: stay out of the way of the picture
• The format decides what styling survives
• Style the language too: glossaries and consistency
• From guidelines to a spec: the project intake
• Acceptance criteria your client can sign
• Our perspective: styling is a delivery problem
• Keeping subtitle versions and approvals in one place
• FAQ
• Sources

The visual basics: font, size, color and background

Start with the boring choice. AIR Media-Tech recommends a sans-serif at medium to bold weight, with Roboto, Arial and Open Sans named as faces that stay legible at speed and ship with most editors. Cursive and decorative faces blur in motion. The Game Accessibility Guidelines make the same argument from the accessibility side: art direction should not override readability, and fully capitalized or stylized text is harder for viewers with hearing loss or lower reading proficiency.

Font size

The most common question here is the number. The same accessibility guidelines say text should be no smaller than 46px at 1080p, either by default or through player options. Scale that proportionally for other resolutions. A 4K master needs roughly double the pixel size to look the same to the viewer.

The real constraint is fit. Your size has to let 42 characters sit comfortably across the frame without crowding the edges. If a line does not fit, shorten the text instead of shrinking the font.

Color, band and contrast

White text on a semi-transparent dark band, around 80% opacity, is the common professional default according to AIR Media-Tech. Drop shadows and outlines work when you can’t use a band, but a band is the safest choice over busy footage.

For accessibility, WCAG 2.2 guidance sets a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text at AA level. The same source advises measuring it with an automated checker against the actual band or footage at the final delivery resolution, rather than trusting a designer’s eye.

A quick reference

Line length, line breaks and reading speed

The widely repeated limits are two lines per subtitle and no more than 42 characters per line, with reading speed held between 15 and 20 characters per second, per the AIR Media-Tech guide. Those limits keep text readable on phones and stop lines running off the screen.

A few habits make the difference between acceptable and polished:

1. Break at natural phrases. Split after punctuation or before a conjunction, never between an article and its noun.
2. Keep the lines balanced. A short top line over a long bottom line looks sloppy and pushes more of the picture under text.
3. Prefer one sentence per subtitle when it fits. Two short sentences can share a subtitle, but a sentence should not split across three events.
4. Time to the audio and the cut. Show text when the speech starts and clear it when the speaker stops. Avoid text that straddles a hard shot change.
5. Edit, don’t transcribe. If a line breaks the reading speed cap, condense it. Fast speech rarely needs a verbatim subtitle.

If you author in a wide typeface, your line breaks survive better. The BBC accessibility guidance notes that the playback device decides the final font, so authoring in a wide face such as Verdana is a common trick to keep your breaks intact if a narrower system font is substituted.

Placement: stay out of the way of the picture

Subtitles live at the bottom, centered or left-aligned depending on the delivery spec, inside the safe area. The goal is to avoid cognitive overload. AIR Media-Tech’s guidance says text that covers faces, on-screen action or lower-third graphics adds strain, and recommends moving it to the top only when the bottom is blocked, so the viewer’s eyes are not forced to jump around.

Two practical notes:

• Use percentages, not pixels. The BBC advises against pixel-based positioning because it fails across resolutions. In XML-based formats such as TTML, specify position as a percentage of the frame. Ekitai Solutions reports that most major platforms reject pixel values for the same reason.
• Plan for vertical versions. If you cut a 9:16 version for social, the safe area changes, and so do your line lengths. This breakdown of delivering 16:9 and 9:16 from one shoot is a useful way to think about framing both from day one, and it applies to where your subtitles land too.

The format decides what styling survives

You can style perfectly and still lose everything at export. Ekitai Solutions summarizes it well: SRT is a universal but basic format that strips styling, WebVTT supports more advanced positioning and styling for web video, and TTML or IMSC 1.1 are required for high-end streaming.

If the platform will strip styles, you have two honest options: burn the subtitles into the picture, or deliver a format like TTML that carries the styling. We cover the tradeoffs in SRT vs VTT and, for broader delivery decisions, in our guide to subtitle file formats.

One more point: burned-in styling takes control away from viewers. The Game Accessibility Guidelines suggest offering customization at the player level instead of forcing hard-coded styles where you can.

Style the language too: glossaries and consistency

A clean font does not rescue inconsistent text. Netflix’s English (USA) Timed Text Style Guide is part of a professional workflow that relies on key names and phrases lists, so character names, terms and cultural references are handled the same way in every episode. Without that, a character’s name appears in three spellings by episode four.

For series, campaigns and multi-language work, build the glossary before the first subtitle is written and treat it as part of the style guide. If you localize into several languages, a roundup of ways to translate YouTube videos can help you match the method to your goal, but the glossary is what keeps the result coherent. Our own checklists go deeper on a six-phase video translation workflow and two-pass QA for subtitle translations.

From guidelines to a spec: the project intake

Most subtitle disputes are not about taste. They come from rules that were never written down. The fix is to collect them at project intake, before anyone opens a subtitle editor.

A workable intake for subtitle work asks:

1. Where will it play? Streamer, broadcast, website, social, event screen. The answer fixes the format and the style limits.
2. Which languages, and who supplies the glossary? Names, product terms and words to leave untranslated.
3. Open or closed? Burned-in, or a separate sidecar file.
4. Does a client style guide already exist? If yes, it overrides your defaults. If not, propose yours and get it approved.
5. Who approves, and by when? Name the single person with sign-off, and the review window.
6. What are the master specs? Frame rate, resolution, aspect ratios, safe area.

If you want the captioning side of this laid out step by step, see a practical captioning workflow for production teams, and our auto-captions workflow if a machine draft is your starting point.

Acceptance criteria your client can sign

Acceptance criteria turn the style guide into pass or fail checks. Each criterion should be measurable by someone who was not in the edit. Here is a template drawn from the numbers above. Adjust any value to match the client’s or platform’s own spec.

Then decide how feedback works. Reviewers should comment against a criterion and a timecode, not against a feeling. Timecoded notes keep that precise, and we explain how to apply them in four rules that fix video comment management and how editors turn comments into NLE markers.

Our perspective: styling is a delivery problem

We see subtitle styling go wrong less from bad taste than from lost context. The spec lives in an email, the glossary in a spreadsheet, the latest SRT on someone’s desktop, and the client’s notes in a chat thread. By delivery, nobody can say which version was approved or against which rules.

That is why we built Posthive around versions, review and delivery in one place, with the client owning the deliverables. A style guide is only useful if everyone is looking at the same one when they review. Our view is simple: write the rules once at intake, attach them to the project, review every subtitle version against them with timecoded comments, and deliver from the same workspace that holds the approval.

And keep the styling plain. Readability wins every argument that matters to the viewer.

— Lorenz

Keeping subtitle versions and approvals in one place

Posthive is a cloud post-production workspace for creative teams, agencies, freelancers and production companies. For subtitle work, that means version control for each subtitle file, collaborative review with client feedback and approval tracking, task and deadline tracking, and secure media delivery. Every plan includes unlimited free seats, so clients and teammates can review without per-editor fees.

The Pro plan is $49 per month and Enterprise is $99 per month; details are on the pricing page. If you want to see how projects and deliverables are organized, start with the workspace structure.

FAQ

What font size should I use for subtitles?

On 1080p video, use 46px or larger, as the Game Accessibility Guidelines recommend. Scale it with resolution, and check that 42 characters still fit across the frame. If they don’t, shorten the text.

What is the best subtitle format?

It depends on where the video plays. SRT is universal but drops styling, WebVTT suits web players, and TTML or IMSC 1.1 are the formats streamers require. For social clips where styling must be exact, burned-in subtitles are the safest option.

How many lines and characters should a subtitle have?

Keep to two lines at most, with about 42 characters per line. Balance the lines and break at natural phrases. Hold reading speed between 15 and 20 characters per second.

What should acceptance criteria for subtitle deliverables include?

List measurable checks: font and size, contrast ratio, line count and length, reading speed, placement, file format, glossary compliance and sync. Agree them with the client at intake so approval is a checklist. Add any platform-specific rules the client’s distributor requires.

Sources

• Guide for writing and formatting subtitles in 2026, AIR Media-Tech
• OTT Subtitling Standards, Ekitai Solutions
• The Typography Accessibility Checklist (WCAG 2.2), Typeyeah
• Game Accessibility Guidelines: present subtitles clearly
• BBC Subtitle Guidelines
• Netflix English (USA) Timed Text Style Guide

Recommended

• Subtitle File Formats: Five Delivery Picks for Production Teams
• Transcript Translation for Production Teams: 5 Stages to TTML/IMSC1
• Production Teams Ship Accurate Subtitle Translations With Two Pass QA
• A Practical Captioning Workflow for Production Teams