Skip to content
optimize

Turn a transcript into an SRT that actually validates.

Timed transcript → SRT → VTT, plus a validator for overlaps, bad numbering, long lines and invalid syntax.

Reviewed 2026-08-17 · runs in your browser where noted · WeaverClip pricing

Loading calculator…

Inputs stay in your browser. WeaverClip never claims ownership of your recordings. Terms · Privacy

SRT Subtitle Generator — subtitles that actually validate

SubRip (.srt) is the oldest and most portable subtitle format in common use, and it is unforgiving in the specific ways plain-text formats always are: a missing blank line, a comma where a period belongs, or a cue numbered out of sequence can make an entire file unload, load partially, or load with timings that drift across the runtime. Most subtitle problems are not content problems — they are syntax problems wearing content symptoms. This page carries both halves of the workflow: a validator that runs six structural checks on any pasted SRT and names each failure precisely, and a generator that turns plain one-sentence-per-line text into a correctly formatted SRT you can refine. Both run locally; neither uploads anything.

The anatomy of an SRT file

An SRT file is a sequence of cue blocks separated by blank lines. Each block has exactly three parts:

  1. A numeric index, starting at 1 and increasing by exactly 1 per cue.
  2. A timing line in the exact form HH:MM:SS,mmm --> HH:MM:SS,mmm — hours, minutes, seconds, and three-digit milliseconds, separated by a comma before the milliseconds, with the arrow between start and end.
  3. The caption text, one or two lines.

That is the entire format. No headers, no metadata, no escape sequences — which is why it has survived twenty years and why every deviation from the shape above is a potential failure point. The arrow is a double hyphen and a greater-than sign with spaces around it; the millisecond separator is a comma, not a period (the opposite of VTT, which trips everyone exactly once); and the blank line between blocks is structural, not cosmetic — parsers use it to find block boundaries.

The six validation checks, and the failure each one catches

1 — Sequential numbering. The validator expects cue 1, then 2, then 3, and flags any deviation with what it expected versus what it found. Why it matters: players that index cues by number misbehave on gaps — some skip, some shift every subsequent cue's association, and some silently drop the tail. Numbering errors are also the signature of a hand-edited file where a cue was deleted without renumbering, so the flag often points at a previous edit's scar.

2 — Timestamp syntax. Each timing line must match the exact pattern, digits in range and comma in place. The most common real-world breaks: a period instead of the comma (usually from a VTT round-trip), two-digit milliseconds instead of three, and a single-digit hour field. The validator names the offending line, which matters because in a 400-cue file "invalid timestamp" without a location is a needle search.

3 — End after start. A cue whose end time is not strictly after its start — equal or earlier — is flagged per cue. Backwards cues usually come from a typo in the seconds field (07,500 becoming 07,400 mid-edit) or from copy-pasting a timing line and updating only one side. Players render backwards cues as missing captions for that window, which viewers experience as "the subtitles glitched right there."

4 — The seven-second reading window. Any cue on screen longer than seven seconds is flagged: "viewer cannot read that fast" is the validator's phrasing, and the check stands for the opposite problem too — a long-duration cue almost always means either too much text parked in one cue or a timing that forgot to close. The number is a reading-speed proxy, derived in the section below.

5 — The 100-character caption cap. Caption text over 100 characters is flagged with a specific remedy: split into two lines of at most 42 characters each. The convention behind the numbers is display geometry — broadcast-style captioning assumes roughly 42 visible characters per line and at most two lines, because that is what fits legibly across TV, desktop player, and phone widths simultaneously. A 100+ character cue will wrap into three or more lines on small screens and cover the picture it exists to serve.

6 — Overlaps. Adjacent cues must not overlap in time: the validator compares each cue's end against the next cue's start and flags inversions. Overlapping captions are the most viewer-visible defect of all — two captions competing for the same moment, one replacing the other mid-sentence — and the most common cause is a missing gap between cues edited in a hurry. Some players render the overlap, others truncate, and the inconsistency across players is why the check exists even though some tools tolerate it.

Reading speed: the math behind the seven seconds

Caption readability reduces to characters per second, and the working range from broadcast practice is roughly 15–20 CPS for comfortable reading — faster for adult drama audiences, slower for children's content and dense technical material. The validator's seven-second window and 100-character cap encode that range: 100 characters over 7 seconds is about 14.3 CPS, near the comfortable floor, which means any cue passing both checks is readable at a relaxed pace. Run the arithmetic on your own cues when in doubt: characters ÷ seconds = CPS, and sustained readings above 20 mean the audience is skimming, not reading — which for subtitles is a quiet failure, because viewers blame their comprehension rather than the captioning. The practical repair for hot cues is always one of two moves: split the text across two cues with a clean clause boundary, or trim the caption to the spoken sentence's load-bearing words (captions may compress speech; they may not invent or distort it).

The generator: plain text to SRT

The second mode takes plain text — one sentence per line — and emits a valid SRT with evenly spaced cues: each cue starts three seconds after the previous one started and stays on screen for 2.8 seconds, leaving a 0.2-second gap that keeps adjacent cues from touching. Numbering, timing syntax, and spacing are correct by construction, which is the point: a generated file passes the validator by definition, giving you a structurally sound skeleton to retime against the actual audio.

Be clear-eyed about what the generator is and is not. It is a drafting and formatting tool: it removes syntax risk and produces clean cue boundaries from your sentence breaks. It is not an alignment tool — it has never heard the audio, so the 3-second grid is a placeholder rhythm, not speech timing. The intended workflow is generate → retime: import the skeleton into your editor of choice and slide cues onto the actual spoken beats, or use it as-is for content where rough timing is acceptable (preview captions, internal reviews, draft deliveries that will be aligned later). For word-accurate alignment, the path is a timed transcript converted with real speech timestamps — and any SRT produced that way should still pass through the validator before shipping, because alignment tools produce overlaps and long cues with impressive regularity.

Generated versus validated: the two workflows, side by side

Validate when you have an SRT that came from somewhere — an editor export, a translation vendor, a platform download, an old project. The six checks locate every structural defect with cue-level precision; fix what is flagged, re-paste, and iterate until the report is clean. The validator never modifies your file; it returns the input untouched plus the issue list, so the editing decisions stay yours.

Generate when you have text and need a file — a cleaned transcript, a script, a translation in plain lines. The generator handles everything mechanical and hands you a valid skeleton. The two modes compose naturally: generate a draft, retime it, then validate the result as the final gate before upload. Making validation the last step — regardless of where the file originated — is the single habit that eliminates the "subtitles won't load" class of problems entirely.

VTT conversion

The download options include a WebVTT export, and the conversion is exactly the three differences the format requires: the WEBVTT header line, milliseconds separated by a period instead of a comma, and no numeric index lines (VTT cues are identified by timing alone). Use VTT where it is required — HTML5 video elements and several platforms expect it — and keep the SRT as your working format, since more tools edit SRT cleanly. One caution: the conversion is one-directional in this tool. If you edit the VTT afterward and need SRT again, the comma/period difference means a paste of VTT into the SRT validator will flag every timing line; convert back at the source or fix the separators deliberately rather than wondering why a healthy file suddenly fails.

The failure modes that never show up as syntax errors

Beyond the six checks, real-world subtitle files break in ways that are worth knowing by name, because they masquerade as other problems. The encoding break: SRT assumes UTF-8 in modern pipelines, and a file saved in a legacy encoding loads with mangled accents or question-mark confetti — the structure validates perfectly while the text is destroyed. The BOM: a byte-order mark at the file's start can make cue 1's index unreadable to strict parsers, producing an error that points at line one of an otherwise clean file. The missing blank line: two cue blocks fused by one absent blank line parse as one malformed cue in most players — the validator's block splitter handles the standard case, but hand-fused blocks are a classic export-time casualty. The trailing space: invisible trailing whitespace on timing lines has killed imports in more than one platform's pipeline. The discipline that catches all of these is simple: when a file validates clean but still misbehaves on a platform, suspect the bytes around the text — encoding, BOM, line endings — rather than the text itself, and re-export with explicit UTF-8 and no BOM.

A repair workflow for a broken file

When a subtitle file arrives damaged — from a vendor, an old export, a round-trip through three tools — the sequence that restores it fastest:

  1. Validate first, fix in order of report. Numbering before timing, because a renumber pass changes nothing else and clears the noisiest flags; syntax next, because broken timing lines block the end-after-start and duration checks on the same cue.
  2. Fix overlaps by deciding ownership. Each overlapped pair is an editorial question: which cue keeps the contested time? Usually the one whose spoken content starts first; adjust the other's boundary to meet it with a small gap.
  3. Split long cues at clause boundaries. The 42-character line convention means splitting where speech naturally pauses — after commas and conjunctions — never mid-phrase, because a caption break inside a phrase reads as a stutter.
  4. Re-validate after every batch of fixes. The issue list is the progress bar; iterate until empty.
  5. Play the repaired file against the video before shipping. Validation proves structure; only playback proves experience — cue boundaries that sit between spoken beats, captions that appear exactly when speech starts, and no window where the screen goes caption-silent while someone is talking.

Writing captions well once the structure is clean

Validation is the floor; readability is the job. The conventions that separate professional captioning from technically-valid captioning: break lines at natural speech boundaries so each line is a single breath-unit; keep speaker identification consistent when multiple voices share a scene (a short label or positional convention, applied uniformly); render significant non-speech — music, sound that matters to the story — in the convention your platform expects, because captions exist for viewers who cannot hear, and an unmarked door slam is a plot hole they never get; and never let captions lag the speech they transcribe, because lag breaks the reading-rhythm that makes subtitles invisible when they are working. The seven-second and 100-character checks keep you inside the readable envelope; these conventions decide whether reading feels effortless or merely possible.

Limits, stated plainly

The validator checks structure, not truth: it cannot tell you whether the text matches the audio, whether the timing follows the actual speech beats, or whether the language is correct — those are alignment and editorial review, which is why playback remains the final gate. The generator spaces cues on a fixed grid and has never heard the recording it captions; treat its output as a skeleton to retime, not a finished alignment. The VTT export converts structure, not style — styling directives that live outside plain SRT are not carried across, because there is nothing to carry. And nothing leaves the browser: pasted subtitles, generated files, and downloads all happen locally, which is exactly the property a pre-release episode's captions need.

FAQ

Why does my SRT use a comma for milliseconds while VTT uses a period? Two formats, two choices, made decades apart. SRT inherited the comma from its European SubRip origins; WebVTT standardized on the period. Converting between them is exactly that substitution plus the header and index differences — and it is the single most common source of "my subtitles stopped working after a format round-trip."

Can a cue have more than two lines? The format tolerates it; the readability convention forbids it. Two lines of ~42 characters is the envelope that survives every screen size, which is why the validator's cap steers you toward splitting instead.

What gap should cues leave between each other? Enough that a viewer perceives the change — typically one or two frames to a few hundred milliseconds. The generator's 0.2-second gap is a safe default; hand-timed files should keep cues from touching at all, because zero-gap boundaries are where overlap bugs breed.

Is it acceptable to compress speech in captions? Yes, within a rule: captions may shorten what was said but must preserve its meaning, and must never add claims the speaker did not make. Compression is a reading-speed tool; invention is misquotation.

My file validates clean but one platform rejects it. What now? Suspect the bytes, not the structure: encoding (re-export as UTF-8 without BOM), line endings, and any platform-specific limits on file size or cue count. Structure validation and platform ingestion are two different gates, and the validator covers the first.

Worked example: diagnosing one broken file

Note for srt-subtitle-generator: The subtitle file below is a hypothetical example — an invented deliverable used to show the diagnostic flow, not a real vendor's work.

A fictional episode's caption file arrives from a translation round-trip, and playback shows captions vanishing halfway through. Pasted into the validator, three issues surface:

"Bad numbering: expected 12, got 13" — someone deleted a cue upstream and never renumbered; every index from the deletion onward is off by one. "End before start in cue 19" — a typo in the seconds field: 00:01:07,400 as the end of a cue that starts at 00:01:07,500. "Overlap: cue 27 ends after cue 28 starts" — two adjacent cues sharing 300 milliseconds.

The repair order follows the report. First renumber the whole file 1 through N — mechanical, safe, done in one pass of any text editor with a macro, or by re-exporting from the source. Second fix cue 19's end time to a value after its start; checking the audio tells you the cue should actually end at 00:01:09,200, and the typo hid a longer timing bug, which is the reason the end-after-start check earns its place in the list. Third resolve the overlap at cue 27/28 by giving each cue its spoken beat: 27 ends where its sentence stops, 28 starts at the next sentence's first word, with a small gap between. Re-validate: clean. Play the file: the mid-episode vanishing is gone, because it was cue 19's backwards timing all along — one typo, one dead window, one false symptom.

Subtitles as reach, not just compliance

The compliance framing — captions exist because accessibility requires them — undersells what captions do. Subtitled content gets watched in sound-off environments where it would otherwise be skipped entirely: feeds, offices, transit, the hours when someone else in the room is asleep. They convert accents and audio quality from barriers into non-issues for every viewer who reads faster than they listen. And they make content indexable and translatable: a validated SRT is the input to every localization workflow, so the structural discipline on this page is also the foundation of every future language version of the same video. The creators who treat caption files as a quality artifact rather than a checkbox consistently find the captions outliving the video — reused, translated, and quoted in ways un-captioned footage never gets.

Language versions and what SRT does not carry

One limitation people discover mid-project: SRT carries text and timing, and nothing else — no language code, no styling, no positioning. Language identity travels by convention (filename suffixes, platform metadata, player configuration), which means a multilingual project's discipline lives in its naming and its platform settings, not in the files themselves. The practical consequence: validate every language file independently, because a file that validates in one language can be broken in another — different average word lengths change line lengths, which changes how often the 42-character convention gets violated, and German or Finnish deliverables routinely fail the caption-length check that the same content's English file passed. Run the same six checks on every language version, and expect the split-and-shorten repairs to concentrate in the longer-word-length languages.

FAQ — a few more

How do I fix a file where every timestamp is shifted by the same amount? That is an offset problem, not a structural one: the file validates clean because all its internal relationships are correct, just displaced. Apply the offset in an editor that supports timing shifts, then re-validate — shifts can push the last cue past the video's end, which playback catches and structure checks cannot.

Can the validator handle very large files? It processes whatever you paste, cue by cue, with no upload involved; the practical limit is your browser's comfort with large text blocks. For multi-hour content, validating in per-reel or per-section chunks works fine, since every check is local to a cue or an adjacent pair.

Why do some players show my captions a frame late or early? Rendering latency varies by player and device, and structure cannot compensate for it; the controllable factor is cue starts, which should sit on the first spoken frame of the sentence rather than a rounded timestamp. If a file plays late everywhere by a constant amount, check for an offset problem as described above rather than blaming the players.

Should captions include filler words? For accessibility captioning, render what was said — hesitation sounds can be omitted without meaning loss, but words with content stay, same standard as the transcript-cleaning matrix elsewhere on this site. The caption record should let a deaf viewer reconstruct the speech, not an idealized version of it.

What is the difference between closed and open captions in this context? SRT files are closed captions — separate, toggleable, and platform-rendered. Burning captions into the picture makes them open: permanent, unstyleable by the viewer, and locked to one language. The validation workflow on this page belongs to the closed-caption world; if you later render captions open, validate first, because a burned-in defect cannot be fixed without re-rendering.

Protect the next recording — verified before delete

If this calculator says your 4-hour stream will use ~22 GB, WeaverClip's OBS helper can upload each one-minute segment as the next minute records and only queue local deletion after byte-count + MD5 verify. Missed segments stay and retry. That is the difference between a number and a guarantee.

Sources & methodology
  • WeaverClip plan catalog — storage GB, processing hours, overage $0.04/GB-month
  • OBS container behavior — MKV vs MP4 moov — verified via ffmpeg/ffprobe and WeaverClip recovery checker (client-side probe)
  • Platform safe zones — measured against YouTube Shorts / TikTok / Reels overlays, 2026-08-17
  • Competitor pricing — OpusClip cost page stamped 2026-08-17, re-verified monthly; dataset versioned