Why a Video Link Shouldn't Always Return a Video

A URL looks like a simple input. But when it points to a social post, the content behind it may be anything but simple.

One post might contain a video. Another might be a photo carousel with a soundtrack. A third might be text only. Treating every URL as “one video in, one MP4 out” makes the interface easy to build, but it can quietly discard useful parts of the post.

Model the result around the post

A better approach is to let the parsed post describe what it actually contains.

For example, a result might include a video URL, a list of image URLs, an audio file, or text and metadata. Some posts can return more than one kind of media. The UI can then render a video preview when there is a video, a gallery when there are images, and separate download actions for files that the platform exposes independently.

This changes the question from “Did the parser find a video?” to “What did this post provide?” That distinction makes the same result model useful across platforms with different post formats.

Keep platform details behind adapters

The shape of a post URL varies too. Short links, canonical post URLs, and platform-specific identifiers all need different handling. Keeping that work in platform-specific adapters helps avoid turning the main request handler into a collection of URL exceptions.

Each adapter can recognize supported post links and map the response into a shared structure. The rest of the application can focus on displaying that structure instead of knowing how every platform names its media fields.

It also makes failures clearer. A profile page, search result, expired short link, or private post is not the same as a supported post with no video. The interface should be able to tell the user what happened rather than showing an empty download area.

Make limitations part of the experience

A parser cannot make private or deleted content public, and it should not ask users for their social account passwords to get around that. Being clear about supported link types and public-content limitations is better than implying every link will work.

I used these ideas while building VideoFlows, a browser-based tool that accepts post links from platforms including TikTok, Instagram, X, Reddit, Bilibili, Douyin, RedNote, Kuaishou, and Weibo. Depending on the post, it can show a video, a photo set, audio, or text rather than forcing every result into a single video-download flow.

The broader lesson applies to any link-based product: normalize the parts that users need, keep source-specific parsing at the edges, and let the interface reflect the content that was actually found.