Building a TikTok Downloader: Streaming, Expiring URLs, Slideshows and MP3

I recently constructed a web service to facilitate downloading public TikTok videos, slideshows, and audio content. While the initial concept of a TikTok downloader appears straightforward—accept a TikTok URL, extract the media URL, download the file, and send it to the user—the reality proves more complex when creating a robust service capable of handling numerous TikTok posts reliably. This article aims to share some of the technical decisions and challenges encountered during its development.

The most apparent architecture involves the following sequence: TikTok → My server → Temporary MP4 file → User. The backend downloads the entire video, stores it on disk, and then returns the file to the user. Although this approach functions effectively, it introduces several unnecessary issues for a public downloader. Every download entails: writing a potentially large file to disk, waiting for the entire file to download before processing, deleting temporary files afterward, managing failed downloads and abandoned files, generating significant disk I/O, consuming more storage as concurrent downloads increase.

Consequently, if 100 users attempt to download videos simultaneously, I don't want 100 temporary MP4 files occupying the server's disk storage unless there's a compelling reason for their presence.

Streaming offers a more efficient alternative to traditional storage methods. Instead of permanently storing the file, the server can read the media response in chunks and forward those chunks to the client. Conceptually, this architecture entails: while (!feof($source)) { echo fread($source, 8192); flush(); }. The real implementation requires proper HTTP headers, timeout handling, connection cleanup, error handling, and other crucial details, but the underlying architecture remains the same.

This approach lowers disk usage, reduces disk I/O, allows downloads to commence earlier, simplifies temporary-file cleanup, and avoids large files occupying local storage. However, it is important to note that streaming does not eliminate the bandwidth problem; it merely shifts it to the server as media passes through it via proxy.

Another tempting approach is to process every video using FFmpeg before sending it to the user. However, this is not generally advisable. If TikTok already delivers a usable MP4 file, re-encoding it would entail: TikTok MP4 → Decode → Encode again → New MP4. This process consumes additional CPU resources, extends processing time, and may compromise video quality.

Therefore, wherever possible, FromTik returns the available media without unnecessary re-encoding. FFmpeg becomes relevant only when the output genuinely necessitates modification, such as extracting MP3 audio or converting a slideshow into a video—a distinct use case from merely downloading an existing MP4.

One crucial aspect to understand is that extracted CDN URLs should not be considered permanent links. TikTok media URLs contain signatures and temporary parameters, meaning a URL that functions now may become obsolete later. Therefore, a workflow like this is unreliable: Extract media URL → Store it in the database → Reuse it tomorrow.

Instead, media information should be treated as short-lived. When a user submits a TikTok URL, the backend extracts fresh information for that specific request. This also influences how caching should be designed. While caching everything for an extended period may seem attractive, caching an expired CDN URL proves useless. TikTok posts are not consistently videos; they can also be photos or slideshows.

Consequently, the downloader service must first identify the type of post it is dealing with. For a regular video, the result may encompass multiple downloadable video variants. For a slideshow, the user may require different formats, such as individual images, all images in a ZIP archive, or the slideshow rendered as a video with sound.

The latter option necessitates actual media processing, as TikTok does not simply provide the slideshow as the exact MP4 output required. Generating a new video file is the appropriate solution in this case.

Treating these two cases differently—pass-through downloads (existing media streamed) and generated downloads (media requiring creation) —avoids performing expensive processing when it is not necessary. Audio also follows a similar distinction, offering two useful outputs: the original audio provided by the source or an MP3 version.

If the original audio is available, it can be returned without conversion. However, if the user specifically requests an MP3, conversion becomes necessary. Once again, the rule is simple: do not transform media unless the requested output truly requires transformation. This approach conserves CPU resources and maintains the original quality whenever feasible.

Quality selection presents an additional challenge. Creating buttons labeled "720p," "1080p," "HD," and "Full HD" is relatively straightforward; however, a downloader cannot magically produce higher-quality sources. If TikTok only offers one viable version of a particular post, conversion is inevitable. The downloader must distinguish between pass-through downloads (existing media streamed) and generated downloads (media requiring creation) to avoid unnecessary processing.

For audio, the same distinction applies—returning the original audio or an MP3 version, depending on the user's preference. This strategy conserves CPU resources and preserves the original quality whenever possible.