From One Short-Video Link to TXT, SRT, and VTT: Building ReelToText
Short-form video is full of useful information, but speech is trapped inside playback. If you want to search a Reel, quote a creator accurately, turn a clip into captions, or study a set of videos, repeatedly pausing and typing is a poor workflow.
I built ReelToText around a simple idea: if a video is public and you already have its link, getting its spoken content should be a link-first task. Paste one public Instagram Reel, YouTube Short, or TikTok URL. ReelToText returns readable text in the browser, plus TXT, SRT, and VTT downloads.
Why link-first instead of upload-first?
A typical transcription workflow asks you to download a video, find the file, upload it, wait, and then clean up another copy of the media. That is a lot of friction for a short public clip.
A link-first workflow keeps the starting point users already have. It also makes product boundaries clearer:
- one individual public short video per request
- Instagram Reels, YouTube Shorts, and TikTok videos
- no private videos, profiles, collection pages, playlists, or batch input
- no permanent source-media library
The narrower scope is intentional. A focused URL contract is easier to validate, explain, and operate than a vague promise to accept every video source.
The workflow
The user-facing flow is four steps:
- Paste a supported public video link.
- ReelToText validates the platform and checks access, limits, and recent cached results.
- The service retrieves the source and transcribes the spoken audio.
- The result appears in the browser and can be copied or downloaded.
The default demo can be tried without an account. To submit your own video, sign in. Verified accounts receive five one-time welcome credits. Free accounts can process videos up to three minutes; active Pro and Max members can process videos up to ten minutes.
Three useful output formats
The transcript is not only a block of text. Different jobs need different exports.
- TXT is best for reading, searching, notes, summaries, translation, and writing.
- SRT includes numbered caption cues and timing, which works with many video editors.
- VTT uses WebVTT timing syntax for compatible web players and web-based caption workflows.
The tool also offers a copy action, so a result can move directly into a note or editing document. Timed formats still need review: speech-to-text can mishear names, numbers, slang, and technical terms, and cue breaks may need adjustment.
A small architecture with deliberate boundaries
ReelToText uses Next.js App Router, React, and TypeScript. The transcript API route coordinates authentication, membership, credits, caching, and the transcription pipeline. Platform-specific source modules keep URL normalization and retrieval rules separate.
The current pipeline uses Apify-based platform retrieval. Instagram and TikTok audio is processed temporarily and sent to OpenRouter Whisper for speech recognition. YouTube Shorts can use a timestamped caption path directly. The API streams progress stages such as access checks, cache checks, audio retrieval, transcription, and result preparation so the interface can explain what is happening.
This separation matters because the external providers can change independently of the product surface. Provider details stay behind a small service boundary, while the user experience remains one URL in and one transcript out.
Cache behavior is part of the product
A transcript tool needs more than a transcription call. The same public video may be requested by many people, and a successful result should not trigger paid provider work every time.
ReelToText keeps recent shared transcript results for 72 hours. A user can reuse their own successful result without paying again, while a shared cached result uses one credit under the current product rules. The public demo is backed by a permanent cache so an anonymous visitor can test the workflow without starting a provider job.
This also makes the cost model easier to reason about. Cache hits, owned-result reuse, provider failures, and content failures are different events. They should not all look like the same generic success or failure state.
Privacy and failure handling
ReelToText does not create a permanent source-media library. Extracted audio is held in server memory for the active request, and the application returns the result to the browser. Media not stored does not mean that media never passes through a server; retrieval and transcription still have to happen somewhere.
The service also distinguishes failures that should not cost the user from failures caused by the submitted content. Invalid URLs are rejected before provider work. Provider, network, and system failures return reserved credits. Some paid-plan content failures can use a disclosed 0.25-credit charge only after the user confirms the policy. That distinction is important for trust in any usage-based product.
What I learned building it
The most useful lessons so far:
- Make supported input narrower than your ambition. Clear rejection is better than unreliable magic.
- Normalize links early. Different share URLs can point to the same content, and caching depends on treating them consistently.
- Design exports at the same time as the transcript. TXT, SRT, and VTT serve different workflows.
- Treat billing states as user experience. Reservation, settlement, refund, and cache reuse need understandable outcomes.
- Keep the original source in view. A generated transcript is a working draft, not proof that every word, name, or timestamp is correct.
If you work with short-form content and need searchable text or caption files, try ReelToText. Paste one public short-video link and see whether a link-first workflow fits your process.
Top comments (0)