A REST API for converting and fixing SRT, VTT, ASS/SSA, SCC and STL subtitle files. Clean output, no forced watermark, no sign-up wall. Get a key, send a file, ship the result.
Get an API Key — Free Need Bulk? See Batch Tool →✓ No account to test✓ No watermark on output✓ Files auto-deleted [TODO:实测时间]
The SRTKit API exposes the same conversion and repair pipeline that powers the web app, wrapped in a plain REST endpoint. Send a subtitle file in one format, get a clean subtitle file back in another — or hand it a broken .srt and get a repaired one in the same format.
Convert between SRT, WebVTT, ASS/SSA, SCC, STL, DFXP/TTML and a few broadcast flavors. Auto-detects input format.
Re-reads files as UTF-8, GBK, Big5, Latin-1, Windows-1252 or Shift-JIS — whichever actually matches the bytes — and writes clean UTF-8.
Shifts every cue by an offset in milliseconds, fixes overlapping timestamps, and snaps out-of-order cues back into chronological order.
Strips BOMs, collapses duplicated cues, removes blank lines, normalizes line breaks, and trims trailing whitespace.
Heads up: the API is a converter and fixer. It does not generate transcripts from audio — that's a separate service and not part of this endpoint. If you need transcripts, see the roadmap below.
One endpoint, two parameters. POST your file as multipart/form-data, tell us the target format, get the converted file back in the response body.
file (required) — the subtitle file. Max [TODO:实测 MB].target_format (required) — one of srt, vtt, ass, ssa, scc, stl, dfxp.fix (optional, default true) — run the repair pipeline (encoding, timing, cleanup) before writing output.offset_ms (optional) — shift every cue by this many milliseconds. Use negative to shift earlier.curl -X POST https://api.srtkit.dev/v1/convert \
-H "Authorization: Bearer YOUR_API_KEY" \
-F "file=@broken.srt" \
-F "target_format=vtt" \
-F "offset_ms=-500"On success, the API returns the converted file with the appropriate MIME type (text/vtt, application/x-subrip, etc.). Headers include:
X-SRTKit-Cues-Processed — number of cues in the output.X-SRTKit-Fixes-Applied — comma-separated list of repair operations that ran (e.g. encoding:GBK->UTF-8,timing:shifted,cleanup:dedup).On error, you get a standard JSON body with error.code and error.message. Status codes follow REST conventions: 400 for bad input, 401 for bad key, 413 for too-large file, 429 for rate limit.
No. Output files come back clean — no banner cues, no brand strings, no dummy entries, no header footers. The same files you'd get from the desktop tool, with the same content you sent in (plus any repairs you opted into).
We don't insert promotional cues, we don't append a "converted with X" disclaimer cue, and we don't downgrade to a paid tier only for clean output. If you're shipping subtitles to a broadcaster or a streaming platform, the file you upload to their system is the file we sent back.
X-SRTKit-Watermark: none so you can grep it out of your pipeline logs.Yes — the API has a free tier so you can prototype without a credit card.
[TODO:实测] requests per day. No credit card. Files auto-deleted after [TODO:实测] hours. Output is watermarked-free.
[TODO:实测] per 1,000 conversions. Higher rate limits, priority queue, larger file size cap.
Custom limits, dedicated support, SLA. Contact for quote.
Rate limits are per API key, not per IP. If you hammer the endpoint from one key, only that key gets throttled — the limit reset is rolling 24h.
Most teams have it running in production within an hour. The endpoint is one HTTP call, the auth is a bearer token, and the response is the file itself — no polling, no webhook plumbing, no SDK required.
curl example above with a real subtitle file.X-SRTKit-Fixes-Applied header in your logs so you can audit what the repair pass did.Sample integrations are available for Node.js, Python and Go on the docs site [TODO:链接实测].
Prefer not to write code yet? The Batch SRT Converter uses the same engine with a drag-and-drop UI — drop in 50 files, get 50 files back, no API key needed.
SRT, WebVTT, ASS, SSA, SCC, STL and DFXP/TTML on both input and output. Input auto-detection is best-effort — if the extension lies about the content, pass source_format explicitly.
Broken files are the whole point. Encoding drift, mojibake, shifted timestamps, duplicated cues, BOM garbage, mixed line endings — the repair pass handles all of these when fix=true (the default). If you specifically want raw conversion with no repairs, send fix=false.
Just REST today. No SDK is required — every HTTP client works. Reference snippets for Node, Python and Go are in the docs. A typed SDK is on the roadmap once the API surface stabilizes.
They're stored for [TODO:实测] hours so you can re-fetch them, then auto-deleted. We don't train on them and we don't share them with third parties.
Yes — generation is on the roadmap as a separate endpoint (/v1/transcribe) to keep this one focused. It will be opt-in and priced separately from conversion.
One REST endpoint. Bearer token auth. Clean output, no watermark. Free tier to start.
Read the Quickstart Try Batch Tool