DEV Community: Web Developer

How X (Twitter) Actually Stores Videos, GIFs, Photos, and Spaces

Web Developer — Fri, 02 Oct 2026 19:00:16 +0000

At first glance, downloading media from X (Twitter) sounds simple.

You have a post URL. You find the media URL. You download the file.

That works — until you realize that a video, an animated GIF, a photo, and a recorded Space are handled in completely different ways.

While working on FromX.app, I had to deal with all of these formats. What surprised me most was how much complexity can sit behind a single input field that just says:

Paste an X link.

Here is what I learned about how X delivers its media.

One post can contain several different kinds of media

A normal X post can contain photos, video, or animated content.

But those media types aren't just different file extensions pointing to the same storage system.

The processing pipeline can look more like this:

X URL
  │
  ├── Video
  │     ├── MP4 variant
  │     ├── MP4 variant
  │     └── HLS representation
  │
  ├── Animated GIF
  │     └── MP4 video
  │           └── optional conversion back to .gif
  │
  ├── Photos
  │     ├── resized timeline version
  │     └── largest available version
  │
  └── Space
        └── HLS audio stream
              ├── segment
              ├── segment
              ├── segment
              └── ...
                    ↓
                   M4A

So even if the user experience is always "paste a URL and download", the work happening behind that button can be very different.

Let's look at each type.

1. Videos: one video can have multiple representations

When you watch a video on X, you aren't necessarily looking at one universal video file.

The same video can be available in several representations with different resolutions and bitrates.

For example, you might find versions roughly corresponding to:

The exact set depends on the source video.

This leads to an important rule for a downloader:

Don't invent quality that doesn't exist.

If the largest version X provides is 720p, displaying a shiny "1080p download" button doesn't magically create Full HD.

You could upscale the video, of course, but that would only create a larger file. It wouldn't restore detail that wasn't present in the source.

For FromX.app, I decided to show the actual qualities available for the post instead.

If X provides 1080p, 720p, and 360p, those are the options.

If it only provides 720p and lower, that's what the user sees.

Direct files vs streaming

Another complication is that video delivery isn't limited to simple direct file URLs.

Depending on the media, you can encounter both directly downloadable variants and HLS playlists.

HLS uses an .m3u8 manifest that describes media streams rather than pointing to one traditional file.

Conceptually:

master.m3u8
    │
    ├── low quality stream
    ├── medium quality stream
    └── high quality stream

This is why media extraction is more interesting than simply searching the HTML for something ending in .mp4.

2. Twitter GIFs aren't really GIFs

This was probably the most amusing part.

Someone uploads an animated GIF to Twitter.

You open the post.

It looks like a GIF.

It loops like a GIF.

But what you're actually watching is typically a video.

X converts animated GIF content into a short looping MP4.

There are good reasons for this.

GIF is an extremely old format. Among other limitations, it uses a limited color palette and is very inefficient for storing longer animations.

A short animation might look like this:

animation.mp4  →  2 MB
animation.gif  →  15 MB

The exact difference varies enormously, but the general pattern is the same: video compression is dramatically more efficient.

So when somebody asks:

"Why does my Twitter GIF download as an MP4?"

The answer is:

Because the MP4 is effectively the media X is serving for that animation.

Converting it back into a real GIF

Sometimes users specifically need a .gif file.

Maybe they're uploading it to an old CMS, a forum, presentation software, or another system that expects GIF rather than MP4.

In that case you need another pipeline:

X animated post
       ↓
      MP4
       ↓
decode frames
       ↓
generate palette
       ↓
encode animated GIF
       ↓
      .gif

Palette generation matters more than I initially expected.

A naive MP4 → GIF conversion can produce ugly banding and poor colors because GIF frames are restricted to a small color palette.

Generating a palette based on the actual animation generally gives much better results.

There is still a trade-off:

the real GIF will usually be much larger than the MP4.

That's not a bug in the downloader. It's simply one of the disadvantages of the GIF format.

So FromX gives both options: keep the smaller original MP4 or convert it into a real animated GIF when you actually need one.

3. Photos: the image in your timeline isn't necessarily the largest one

Photos seem much easier than videos.

And, comparatively, they are.

But there's still one detail worth knowing.

The image displayed inside the timeline doesn't need to be the largest version available.

Social platforms generate resized versions because sending a huge image to everyone scrolling through a feed would waste bandwidth.

Conceptually:

Uploaded image
     │
     ├── small preview
     ├── medium version
     ├── large version
     └── largest available version

For a downloader, the goal shouldn't be:

Download the exact image currently displayed in the browser.

It should be:

Find the largest version X makes available.

That's the version FromX requests.

There is also an important distinction here.

When I say "original", I mean the largest version stored by X, not necessarily the untouched byte-for-byte file that existed on the uploader's computer before it was posted.

X may already have processed the image.

A downloader cannot recover information that the platform itself discarded.

This is another case where it's better not to promise something technically impossible.

Multiple photos introduce another small problem

A post can contain several photos.

Downloading one file is trivial.

Downloading four photos isn't difficult either, but asking the user to click four separate buttons isn't a great experience.

So there are really two useful outputs:

Post
 ├── photo_1.jpg
 ├── photo_2.jpg
 ├── photo_3.jpg
 └── photo_4.jpg

or:

post_photos.zip
 ├── photo_1.jpg
 ├── photo_2.jpg
 ├── photo_3.jpg
 └── photo_4.jpg

The ZIP itself doesn't need to modify the images.

It can simply package the existing files together.

It's a tiny feature technically, but it makes multi-photo posts much more convenient to save.

4. Spaces are completely different

Then there are X Spaces.

A recorded Space looks like one long audio file from the user's point of view.

Technically, that's not necessarily how it's delivered.

Recorded Spaces are served through streaming infrastructure using HLS.

Instead of:

space.m4a

you may be dealing with something closer to:

playlist.m3u8

segment0001
segment0002
segment0003
segment0004
...
segment2500

A long Space can contain thousands of small audio fragments.

To produce something useful for offline listening, those fragments need to be retrieved in the correct order and combined.

The simplified process looks like this:

Space URL
    ↓
recording metadata
    ↓
HLS playlist
    ↓
audio segments
    ↓
assemble in order
    ↓
M4A file

This is fundamentally different from downloading a photo or grabbing a direct MP4 URL.

Why M4A?

The Space audio is based on AAC.

Instead of decoding that audio and encoding it again into MP3, you can preserve the existing audio stream and package it inside an M4A container.

That has a major advantage:

no unnecessary re-encoding.

Every lossy re-encode has the potential to reduce quality.

If the source is already AAC and your goal is simply to make it easy to save and play, keeping that audio makes sense.

The result works well for long recordings too.

A two-hour discussion doesn't need to become an enormous video file when the user only wants the audio.

Avoid conversion whenever possible

This became one of the main principles I followed while building the service.

If the platform already provides a useful file, don't convert it just because you can.

For example:

X MP4 → Download MP4

is better than:

X MP4
   ↓
decode
   ↓
re-encode MP4
   ↓
download

The second approach:

consumes CPU;
takes longer;
can reduce quality;
creates temporary files;
increases server bandwidth and storage requirements;
gives the user almost nothing in return.

The same applies to Spaces.

If you can preserve the original AAC audio, there is little reason to encode the entire recording again unless the user specifically asks for another format.

Conversion should solve a real compatibility problem.

It shouldn't be the default.

A simple UI can hide very different backend jobs

This was probably my biggest takeaway.

From the user's perspective, the workflow for every format is identical:

1. Copy URL
2. Paste URL
3. Download

But internally the jobs can be completely different.

A photo might only require locating the correct image URL.

A video requires discovering available representations.

A GIF requires recognizing that the "GIF" is really a video and optionally running a conversion pipeline.

A recorded Space requires processing a streaming playlist containing potentially thousands of segments.

Yet all of them begin with the same thing:

https://x.com/username/status/...

or:

https://x.com/i/spaces/...

That's one of the things I enjoy about building small tools: sometimes the simplest interfaces sit on top of the most interesting technical problems.

What I ended up building

These experiments eventually became FromX.app.

It handles public X media through one input and currently supports:

videos in the qualities X makes available;
animated posts as their MP4 or converted GIF;
photos in the largest available size;
multiple photos as a ZIP;
audio extracted from videos;
recorded Spaces as M4A;
profile pictures;
profile headers.

There is no account required.

The more interesting part for me, though, wasn't building another download button.

It was learning that "download media from Twitter" isn't really one problem.

It's several unrelated media pipelines hidden behind one URL.

Final thought

Modern websites increasingly hide storage and delivery details behind players, dynamic APIs, manifests, CDNs, and streaming protocols.

What looks like:

[ Download ]

might mean:

find metadata
→ identify media type
→ discover variants
→ parse a playlist
→ fetch hundreds of fragments
→ remux streams
→ optionally convert formats
→ send the result

And sometimes the animated GIF isn't even a GIF.

That part is still my favorite.

Downloading an Entire Facebook Photo Album as a ZIP: How I Built It

Web Developer — Tue, 22 Sep 2026 17:14:28 +0000

Downloading a single photo from Facebook is easy enough.

Downloading an entire album is a different story.

If an album contains dozens of photos, saving them one by one quickly becomes tedious. I wanted a simpler workflow: paste a Facebook album URL, retrieve all available photos, and download the entire album as a single ZIP file.

That idea eventually became one of the features in FromFB.

In this post, I'll explain the basic architecture behind the feature, some of the problems I had to solve, and a few things I learned while building it.

The Goal

The user experience I wanted was very simple:

Paste Facebook album URL
        ↓
Analyze the album
        ↓
Show available photos
        ↓
Download individual photos
        ↓
or
        ↓
Download everything as ZIP

The UI is the easy part.

Most of the work happens behind the scenes.

The application has to identify the URL, extract the available media, prepare the files, and generate an archive without making the user wait unnecessarily long.

Step 1: Detecting What the User Submitted

The first step is URL validation.

A downloader shouldn't simply accept arbitrary input and immediately start making server-side requests.

At a minimum, I need to determine whether the submitted URL is actually a supported Facebook URL and whether it points to content the application knows how to process.

Conceptually, the flow looks like this:

Submitted URL
     ↓
Validate URL
     ↓
Identify Facebook content type
     ↓
Album / Photo / Video / Reel / Unsupported

This is important because the processing logic for an album is very different from the logic required for a single video or image.

It also keeps the backend cleaner.

Instead of having one huge function trying to figure everything out, the application can route different content types to different handlers.

Step 2: Extracting the Album Photos

Once an album is detected, the next task is retrieving its available photos.

The result I want internally is something simple, such as:

[
  {
    "id": "photo_1",
    "url": "https://example.com/photo1.jpg"
  },
  {
    "id": "photo_2",
    "url": "https://example.com/photo2.jpg"
  },
  {
    "id": "photo_3",
    "url": "https://example.com/photo3.jpg"
  }
]

The actual extraction process is naturally more complicated than that, but separating extraction from downloading makes the rest of the system easier to maintain.

The extractor's job is basically:

Facebook album URL
        ↓
Retrieve album information
        ↓
Find available photo resources
        ↓
Normalize results
        ↓
Return a clean list to the application

The downloader doesn't need to care how those URLs were discovered.

It just needs a predictable result.

That separation became especially useful as I added support for different Facebook content types.

Step 3: Individual Downloads vs. ZIP Downloads

After extracting the photos, I wanted to offer two options.

Users can download individual images, or they can download the complete album.

Individual downloads are straightforward.

ZIP downloads introduce another layer:

Photo URLs
    ↓
Download photos
    ↓
Generate filenames
    ↓
Add files to ZIP
    ↓
Return ZIP to the browser

For example:

facebook-album/
├── photo-001.jpg
├── photo-002.jpg
├── photo-003.jpg
├── photo-004.jpg
└── photo-005.jpg

Then the application can produce something like:

facebook-album.zip

That sounds simple, but there are a few details that matter.

File Naming

Using the original filenames isn't always practical.

Media URLs can contain long or meaningless identifiers, query parameters, or filenames that aren't especially useful once downloaded.

So I prefer predictable names:

photo-001.jpg
photo-002.jpg
photo-003.jpg
...

This also preserves the order of the album.

If there are 100 photos, padding the numbers keeps sorting consistent:

photo-001.jpg
photo-002.jpg
...
photo-099.jpg
photo-100.jpg

Small detail, but it makes the resulting ZIP much nicer to use.

Temporary Storage

Another question was whether downloaded photos should remain on the server.

For this type of service, I don't want files sitting around permanently.

A better workflow is:

Create temporary job
        ↓
Download required images
        ↓
Create ZIP archive
        ↓
Send archive to user
        ↓
Remove temporary files

Temporary files still require proper cleanup.

If even a small percentage of jobs fail before cleanup happens, disk usage can slowly grow over time.

So cleanup shouldn't depend only on the successful end of a request.

It's useful to have a second cleanup mechanism that removes abandoned temporary files after a certain period.

For example:

/tmp/downloads/job-123/
/tmp/downloads/job-456/
/tmp/downloads/job-789/

A scheduled cleanup process can periodically remove old directories that are no longer in use.

Memory Usage Matters

A tempting approach is to download every photo into memory and then create the archive.

That works for small albums.

It becomes a bad idea very quickly when users process larger ones.

Imagine:

50 photos × 5 MB = 250 MB

Keeping all of that in memory for a single request is unnecessary.

With multiple simultaneous users, memory consumption can grow very quickly.

The safer approach is to stream or temporarily write files to disk and let the ZIP process work with those files.

Instead of:

Internet → RAM → ZIP

the flow becomes closer to:

Internet
   ↓
Temporary file
   ↓
ZIP archive
   ↓
User

It's slightly more work, but considerably more predictable.

Handling Failed Images

Another issue is partial failure.

Suppose an album contains 40 photos.

The first 35 download correctly, but one remote request fails.

Should the entire operation fail?

Usually, that's not the best user experience.

Depending on the situation, it's often better to continue processing the remaining files and return the successfully retrieved photos.

Conceptually:

for each photo:
    try download
    if successful:
        add to archive
    else:
        record failure
        continue

The user can still get 39 out of 40 images rather than receiving nothing.

This also makes the application more resilient to temporary network problems.

Timeouts

External media downloads are unpredictable.

A remote server may respond immediately, slowly, or not at all.

Without reasonable timeouts, one failed request could keep an entire job stuck.

So each network operation needs limits.

The exact numbers depend on the infrastructure, but the general principle is simple:

Never let one external request block a download job indefinitely.

Retries can also help, but they should be limited.

Something like this conceptually:

Request image
    ↓
Success? → Continue
    ↓ No
Retry
    ↓
Success? → Continue
    ↓ No
Skip / report failure

Infinite retries are usually worse than the original problem.

ZIP Creation

Once the images are available locally, creating the archive is comparatively simple.

In PHP, the basic idea might look like this:

$zip = new ZipArchive();

$zip->open($zipPath, ZipArchive::CREATE | ZipArchive::OVERWRITE);

foreach ($photos as $index => $photoPath) {
    $filename = sprintf('photo-%03d.jpg', $index + 1);

    $zip->addFile($photoPath, $filename);
}

$zip->close();

The interesting part isn't the ZIP code itself.

The challenging part is everything around it:

downloading multiple remote files safely;
avoiding excessive memory usage;
handling failed downloads;
cleaning temporary files;
preventing duplicate work;
keeping response times reasonable.

The archive is only the final step.

Preventing Duplicate Processing

There's another optimization that's easy to overlook.

A user may click the download button multiple times.

Two users might also request the same album around the same time.

Without protection, the server could start several identical jobs:

Album A → Job 1
Album A → Job 2
Album A → Job 3

Depending on the architecture, it can be useful to temporarily identify active jobs and reuse the result when appropriate.

For example:

hash(normalized_album_url)

can serve as part of a temporary job identifier.

This isn't always necessary for a small service, but it becomes more useful as traffic increases.

Keeping the Frontend Simple

Despite everything happening in the backend, I wanted the frontend to remain simple.

The user shouldn't have to understand any of this.

They should see something like:

Paste URL
   ↓
Download
   ↓
Photos appear
   ↓
Download individually
or
Download all as ZIP

A good tool hides its infrastructure.

If the user has to understand jobs, archives, media extraction, temporary storage, or retries, the abstraction has failed.

What I Learned

The biggest lesson from building this feature is that the visible part of a downloader is usually the easiest part.

The form itself may contain one input and one button.

Behind that button you may have:

URL validation
→ content detection
→ media extraction
→ network requests
→ temporary storage
→ retry handling
→ archive creation
→ streaming
→ cleanup

This is true for many small SaaS and utility projects.

A feature that looks trivial from the outside can contain a surprising number of edge cases once real users start using it.

The Result

I added the album downloading feature to FromFB, my Facebook media downloader.

The photo downloader can process supported Facebook photo content and lets users download available images individually or package album photos into a ZIP archive.

You can try it here:

https://fromfb.app/en/facebook-photo-downloader

The project also supports other types of Facebook media, but album downloads were particularly interesting to build because they involve much more than simply returning a single file.

I'm continuing to improve the service as I encounter new edge cases.

If you're building something similar, I'd be interested to hear how you handle bulk downloads, temporary storage, and ZIP generation.

Building a YouTube Shorts Downloader: Why It’s Harder Than It Looks

Web Developer — Fri, 18 Sep 2026 17:05:41 +0000

Paste a URL, click a button, get an MP4.

At first glance, a YouTube Shorts downloader sounds like one of the simplest web tools you could build.

But once you go beyond the prototype stage, things become more interesting.

You have multiple video formats, separate audio and video streams, different codecs, FFmpeg merging, audio conversion, temporary files, bandwidth usage, and a source platform that can change its behavior at any time.

In this post, I want to explain what actually happens behind a seemingly simple Download button.

The basic flow

From the user's perspective, the process looks like this:

YouTube Shorts URL
        ↓
Paste URL
        ↓
Choose quality
        ↓
Download MP4

On the server, the pipeline is closer to:

URL
 ↓
Validate URL
 ↓
Extract video metadata
 ↓
Detect available formats
 ↓
Select video/audio streams
 ↓
Download required streams
 ↓
Merge or convert if necessary
 ↓
Return the final file

Most of the complexity is hidden between "detect available formats" and "return the file."

YouTube doesn't always give you one ready MP4

One of the first things you notice when working with YouTube media is that a video is not necessarily available as one convenient file containing both high-quality video and audio.

Higher-quality formats commonly use separate streams.

You may have something conceptually like:

1080p video
video only

and separately:

audio
audio only

If the user asks for a 1080p MP4, you may therefore need to download both streams and combine them.

So instead of:

YouTube → MP4

the process becomes:

YouTube
   ↓
1080p video stream
   +
audio stream
   ↓
FFmpeg
   ↓
final.mp4

For the user, this still looks like one download.

For the server, it can mean two network transfers plus additional processing.

Why FFmpeg becomes important

FFmpeg is one of the most useful tools in this kind of project.

If the video and audio are already encoded in compatible formats, FFmpeg can often combine them without re-encoding everything.

A simplified example looks like:

ffmpeg -i video.mp4 -i audio.m4a -c copy output.mp4

This is much better than unnecessarily converting the entire video because copying existing streams is faster and uses less CPU.

But format compatibility matters.

You cannot assume every video stream and every audio stream can simply be placed into every container.

This is why format selection becomes an important part of the application instead of blindly choosing the file with the highest resolution.

Format selection is more complicated than resolution

A user sees options like:

360p
720p
1080p

A downloader sees much more information:

container
video codec
audio codec
bitrate
resolution
FPS
video-only / audio-only
file size

For example, two formats may both be 1080p but use different codecs.

One might be more convenient for MP4 delivery, while another might be optimized for WebM.

So choosing a format only by height is not enough.

You need some selection logic.

Conceptually:

requested resolution
        ↓
find compatible video stream
        ↓
find suitable audio stream
        ↓
determine whether merging is required

This gets even more important when the original Short does not have the exact quality requested by the user.

A downloader should not pretend that a 720p source suddenly became real 1080p.

MP3 is another interesting case

Downloading audio also has two different scenarios.

If the original audio stream is already available in a useful format such as M4A, the service may be able to deliver that stream without converting it.

MP3 is different.

You generally need to extract or convert the audio:

YouTube video
     ↓
audio stream
     ↓
FFmpeg
     ↓
MP3

There is also an important misconception around audio quality.

Converting a lower-bitrate source into:

320 kbps MP3

does not magically add quality that didn't exist before.

It only creates an MP3 encoded at that bitrate.

The source quality still determines the actual amount of audio information available.

Why I decided to support only YouTube Shorts

When building FromYT, I intentionally focused on Shorts instead of trying to support every possible YouTube URL.

That decision simplifies the product in several ways.

Short videos mean smaller files, shorter processing times and lower bandwidth requirements.

Compare processing a 30-second Short with processing a three-hour video.

Even if the underlying extraction process is similar, the infrastructure requirements are completely different.

Large videos can require:

more bandwidth
more temporary storage
longer HTTP connections
longer FFmpeg processes
higher failure probability

Limiting the service to Shorts gives the application a much more predictable workload.

It also keeps the purpose of the site clear.

Instead of becoming another generic downloader supporting dozens of platforms and media types, FromYT does one specific thing.

Temporary files need attention

If the server has to merge streams, it normally needs temporary files.

For example:

/tmp/job-123/video.mp4
/tmp/job-123/audio.m4a
/tmp/job-123/final.mp4

Those files must eventually disappear.

If they don't, disk usage can grow surprisingly quickly.

Imagine an average processing job temporarily using 50 MB.

With 10,000 jobs, that's potentially:

50 MB × 10,000 = 500 GB

Of course, you should delete files after each job, but failures also need to be considered.

What happens if FFmpeg crashes?

What happens if the user closes the page?

What happens if the network request times out halfway through?

Cleanup should therefore not rely only on the application's normal success path.

A periodic cleanup process is useful as a second layer of protection.

Bandwidth can become more important than CPU

At first, I expected media processing to mostly be a CPU problem.

In many cases, bandwidth is actually the bigger concern.

Consider a simplified example.

A user downloads a 40 MB video.

Your server may need to:

download 40 MB from the source
+
send 40 MB to the user

That is already around 80 MB of transfer associated with one request.

If separate streams are required, there may be multiple source downloads before the final file is sent.

At scale, even relatively small videos create a lot of traffic.

For services like this, bandwidth planning can become just as important as application optimization.

Another problem: the source platform keeps changing

A normal web application communicates with APIs and systems you control.

A downloader depends on a platform you don't control.

That changes the maintenance model.

Something that works today may stop working because of changes to:

page structure
player behavior
video formats
JavaScript
request validation
rate limits
bot detection

This is one reason tools such as yt-dlp are so valuable.

A huge amount of platform-specific extraction logic is maintained by the open-source community.

Instead of implementing every extraction rule yourself, your application can focus on everything around it:

validation
queues
format selection
rate limiting
storage
FFmpeg processing
error handling
delivery
UI

But it also means keeping the extraction layer updated is part of running the service.

A downloader is not really a "build it once and forget it" type of application.

Error handling matters more than I expected

There are many reasons a download may fail.

For example:

invalid URL
deleted video
private video
unavailable video
age restriction
temporary network failure
format unavailable
extraction failure
FFmpeg failure

Simply returning:

Something went wrong

is easy, but it creates a bad user experience.

It's better to categorize failures whenever possible.

For example:

This video is unavailable.

This URL is not a YouTube Short.

The requested quality is not available.

The video could not be processed. Please try again.

Good error messages are especially important for tools where the user cannot see what is happening behind the scenes.

Protecting the service from abuse

Any public endpoint that triggers network requests or media processing can be abused.

Without limits, someone could automate thousands of download requests.

So even a simple downloader eventually needs things such as:

rate limiting
maximum video duration
request validation
concurrency limits
timeouts
job limits

The purpose is not only protecting the server from malicious users.

Limits also prevent accidental overload.

A small number of users running many expensive requests simultaneously can have the same effect as intentional abuse.

The UI should hide most of this complexity

The funny part is that, after implementing all of this, the best frontend is still extremely simple.

The user should see something like:

Paste YouTube Shorts URL
        ↓
Choose format
        ↓
Download

They should not have to understand codecs, adaptive streams, muxing or FFmpeg.

All of that complexity exists specifically so the user doesn't have to think about it.

That is one of the things I enjoy about building small web tools.

The simpler the interface looks, the more engineering may be hidden behind it.

What I ended up building

I eventually turned this experiment into FromYT.net:

https://fromyt.net/en

It is focused specifically on YouTube Shorts and currently supports downloading video in different available qualities as well as extracting audio.

The project is intentionally narrow.

I would rather keep one small tool reliable than add every possible media platform immediately.

What I learned

Building the first prototype was easy.

Making it something I would actually want people to use required thinking about much more than downloading a video.

The most important lessons were:

Media downloading is partly an infrastructure problem.
Higher resolution often means separate video and audio streams.
FFmpeg is incredibly useful for merging and conversion.
Bandwidth becomes expensive faster than expected.
Temporary files require reliable cleanup.
Format selection needs more logic than simply choosing the highest resolution.
Third-party platforms can change at any time.
Narrowing the scope of a product can dramatically simplify its infrastructure.

The final result is still just a box where you paste a URL and press a button.

And that's probably exactly how it should be.

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

Web Developer — Fri, 18 Sep 2026 16:51:33 +0000

Recently, I built a small web service for downloading public TikTok videos, slideshows, and audio.

At first, a TikTok downloader sounds like a very simple project:

Accept a TikTok URL
Extract the media URL
Download the file
Send it to the user

But once you try to turn this into a real service that has to work reliably for many different TikTok posts, things become more interesting.

In this article, I want to share some of the technical decisions and problems I encountered while building it.

The obvious architecture

The most straightforward implementation looks like this:

TikTok
  ↓
My server
  ↓
Temporary MP4 file
  ↓
User

The backend downloads the whole video, saves it somewhere on disk, and then returns the file to the user.

This works.

But for a public downloader, it also creates several unnecessary problems.

Every download means:

writing a potentially large file to disk;
waiting for the full file to download before processing it;
deleting temporary files afterward;
handling failed downloads and abandoned files;
generating a lot of disk I/O;
consuming more storage as concurrent downloads increase.

If 100 users are downloading videos at the same time, I don't really want 100 temporary MP4 files sitting on the server unless there is a good reason for them to be there.

Streaming instead of storing

For regular video downloads, there is usually no need to permanently store the file.

A better flow is closer to this:

TikTok CDN
     ↓
   Server
     ↓
 streaming response
     ↓
    User

The server can read the media response in chunks and forward those chunks to the client.

Conceptually:

while (!feof($source)) {
    echo fread($source, 8192);
    flush();
}

The real implementation needs proper HTTP headers, timeout handling, connection cleanup, error handling, and other details, but the important part is the architecture.

The entire video does not need to exist as a completed temporary file before the user can receive it.

This has a few advantages:

lower disk usage;
less disk I/O;
downloads can start earlier;
temporary-file cleanup becomes much simpler;
large files don't need to occupy local storage.

Of course, bandwidth still passes through the server if the media is proxied this way. Streaming removes the storage problem, not the bandwidth problem.

Why not re-encode every video?

Another tempting approach is to process every video with FFmpeg before sending it to the user.

For most normal downloads, I don't think that makes sense.

If TikTok already provides a usable MP4 file, re-encoding it would mean:

TikTok MP4
    ↓
Decode
    ↓
Encode again
    ↓
New MP4

That adds CPU usage, increases processing time, and may reduce video quality.

So wherever possible, FromTik returns the available media without unnecessarily re-encoding it.

FFmpeg becomes useful when the output actually needs to be changed—for example, extracting MP3 audio or turning a slideshow into a video.

That is a very different use case from simply downloading an existing MP4.

Media URLs are temporary

One of the more important things to understand is that extracted CDN URLs should not be treated as permanent links.

TikTok media URLs can contain signatures and temporary parameters.

A URL that works now may stop working later.

That means a workflow like this is unreliable:

Extract media URL
      ↓
Store it in database
      ↓
Reuse it tomorrow

Instead, media information should generally be treated as short-lived.

When a user submits a TikTok URL, the backend extracts fresh information for that request.

This also changes how caching should be designed.

Caching everything for a long time sounds attractive, but caching an expired CDN URL isn't very useful.

A TikTok post isn't always a video

Another thing I underestimated initially is that "TikTok downloader" does not mean only downloading MP4 files.

TikTok also has photo/slideshow posts.

So the service has to first identify what kind of post it is dealing with.

A simplified version looks like this:

TikTok URL
    ↓
Extract metadata
    ↓
┌───────────────┬─────────────────┐
│ Video post    │ Slideshow post  │
└───────────────┴─────────────────┘

For a normal video, the result may contain several downloadable video variants.

For a slideshow, the user may want something completely different.

On FromTik, slideshow posts can be downloaded in different forms:

individual images;
all images inside a ZIP archive;
the slideshow rendered as a video with sound.

The last option requires actual media processing, because TikTok doesn't simply provide the slideshow as the exact MP4 output I want to give the user.

Turning a slideshow into a video

This is one of the cases where generating a new file makes sense.

The process is roughly:

Images + audio
      ↓
    FFmpeg
      ↓
Generated MP4

Unlike a regular TikTok video, there isn't always an existing MP4 that can simply be forwarded.

So this is where CPU usage and temporary storage become part of the problem.

It also means the architecture should distinguish between two types of downloads.

Pass-through downloads

Existing media can be streamed:

CDN → Server → User

Generated downloads

Media has to be created first:

Images / Audio
       ↓
    Processing
       ↓
 Temporary output
       ↓
      User

Treating these two cases differently avoids doing expensive processing when it isn't needed.

Audio has the same distinction

The audio downloader follows a similar idea.

There are two useful outputs:

the original audio provided by the source;
an MP3 version.

If the original audio is already available, it can be returned without converting it.

If the user specifically wants MP3, conversion becomes necessary.

Again, the rule is simple:

Don't transform media unless the requested output actually requires transformation.

It saves CPU and keeps the original quality whenever possible.

HD is more complicated than a button

Another interesting problem is quality selection.

It is easy to create buttons labeled:

720p
1080p
HD
Full HD

But a downloader cannot magically create a higher-quality source.

If TikTok only provides one useful version of a particular post, converting it into a larger resolution doesn't suddenly create more detail.

So I prefer to expose higher-quality options only when an appropriate source actually exists.

Otherwise, an "HD" button risks becoming little more than marketing.

Error handling matters more than expected

A media downloader depends heavily on another platform.

That means many things can go wrong even when your own application is working perfectly:

the post was deleted;
the post is private;
the URL is malformed;
TikTok changed something;
the media URL expired;
a CDN request failed;
extraction returned incomplete information;
the connection was interrupted midway through a download.

One of my goals with FromTik was therefore not just to make downloads work, but to make failures understandable.

A user should ideally see something meaningful instead of waiting for 30 seconds and eventually getting a generic 500 error.

This sounds obvious, but when testing other downloaders, I noticed that failed requests often result in exactly that kind of experience: a long loading state followed by an unexplained error.

Reliability is probably more important for this kind of service than adding another minor feature.

What I learned

The biggest lesson from building the project was that the downloading part itself isn't necessarily the most difficult part.

The interesting engineering decisions are around it:

when to stream and when to store;
when to use FFmpeg and when not to;
how to handle temporary CDN URLs;
how to support different types of posts;
how to avoid unnecessary processing;
how to recover gracefully when the upstream platform changes or fails.

The architecture I ended up with is therefore less like:

URL → download file

and more like:

                  ┌─ Stream existing video
                  │
TikTok URL → Parse ├─ Return original audio
                  │
                  ├─ Convert audio to MP3
                  │
                  ├─ Download slideshow images
                  │
                  └─ Generate slideshow video

The input looks simple, but the correct processing path depends on what the user actually requested.

The project

The service is available at:

https://fromtik.net/en

It currently supports TikTok videos, slideshows, and audio downloads.

I'm still improving it, especially around reliability and handling different types of TikTok content.

If you've built a similar media-processing service, I'd be interested to hear how you handle streaming, temporary files, and upstream platform changes.

Building Instagram Downloader: Turning a Simple Downloader Into a Real Product

Web Developer — Thu, 17 Sep 2026 18:05:57 +0000

At first, Instagram Downloader sounded like a small project.

A user pastes a public Instagram link, the service finds the media, and the browser downloads it. Simple.

But “simple” products are often the ones that require the most care. The user sees one input field and one button. Behind that interaction are dozens of decisions about usability, different media types, mobile behavior, accessibility, localization, reliability, and privacy.

This is the story of how FromInsta.net grew from a basic downloader into a focused web product.

Starting with one clear promise

The first version was built around a single workflow:

Copy a link to a public Instagram post.
Paste it into the service.
Choose the media you want to save.

There was no reason to make the interface more complicated than that. Users arrive with a very specific goal, so the page needs to help them complete it without registration, unnecessary settings, or a long explanation.

That principle remained important as the product expanded: new features should support the original workflow instead of competing with it.

A download button was not enough

The earliest product question was not simply whether a file could be downloaded. It was whether users could understand what they were about to download.

Instagram posts can contain a single photo, a video, a Reel, or a carousel with multiple items. A generic button does not communicate much when a post contains several files.

Media previews became an essential part of the experience. Users could inspect photos, play videos, move between carousel items, and then save exactly what they needed.

This changed the service from a link-processing utility into a visual workflow:

Paste, preview, choose, download.

Small interaction details also mattered. The interface needed clear loading states, useful error messages, predictable mobile controls, and an obvious way to recover when a request failed.

None of these features sounds remarkable on its own. Together, they determine whether a service feels dependable.

Audio became a product of its own

Downloading photos and videos was only part of the use case. Sometimes the valuable part of a Reel or video is its audio.

Adding audio support required a different user experience. Audio may need time to be prepared, so an immediate download is not always possible. Users need to know whether their request is waiting, being processed, ready, or no longer available.

The final experience lets users preview the audio and choose between the original available format and MP3. For carousel posts, the service processes the video items that contain audio and skips photos.

The important lesson was that audio could not simply be added as another button. It had its own states, expectations, and failure cases, so it deserved a dedicated flow.

Carousels exposed another kind of friction

A carousel may contain photos, videos, or a mixture of both. Downloading every slide individually works, but it becomes repetitive for larger posts.

That led to an option to save a complete carousel as a single ZIP archive.

Again, the main challenge was not presenting another feature. It was making the feature understandable:

Individual files should still be available.
Users should be able to preview each item.
The complete archive should be optional.
Temporary files should not appear permanent.

The result gives users both levels of control: save one specific item or download the full collection.

Localization changed more than the text

FromInsta.net is now available in 24 languages.

Localization initially looked like a content task, but it quickly became a design task. Labels become longer. Headings wrap differently. Some scripts require more space. Arabic and Persian introduce right-to-left layouts. Technical Instagram terminology does not always have a natural word-for-word translation.

Each language also needs more than a translated homepage. Navigation, instructions, errors, download states, accessibility labels, legal pages, and metadata must all remain consistent.

This taught us to treat localization as part of the product rather than as a final layer added after development.

A multilingual interface is not complete when every string has been translated. It is complete when every supported language can go through the entire workflow comfortably.

Mobile usability had to be treated as the default

Copying an Instagram link and opening a downloader is a naturally mobile workflow. That means mobile behavior cannot be a reduced version of the desktop experience.

Several details became especially important:

The link field must remain easy to use on a narrow screen.
Paste and clear actions must be easy to reach.
Security checks must fit without breaking the layout.
Preview controls must not cover the media.
Download buttons need clear pressed and disabled states.
Results should come into view when they are ready.

These improvements are easy to overlook when testing on a large screen. On a phone, they define the entire experience.

Reliability is a user-facing feature

Services that depend on another platform must expect change.

A link that works today may behave differently tomorrow. A post may be private, removed, restricted, or temporarily unavailable. A video may not contain an audio track. A request may take longer than expected.

Trying to hide this uncertainty would only create confusing failures. The better approach was to communicate it clearly.

FromInsta.net distinguishes between invalid links, unavailable posts, unsupported media, timeouts, processing problems, and temporary service errors. Users should know whether they can correct the problem, retry later, or whether the source itself is unavailable.

Monitoring and routine health checks also became part of the product’s development. They are invisible during normal use, but they reduce the time between a platform change and a fix.

Reliability is not only about preventing errors. It is also about making errors understandable.

Privacy boundaries should be visible

From the beginning, the service was designed for publicly available Instagram content.

It does not ask for an Instagram username, password, verification code, or access to a private account. Private, removed, and login-only posts are outside the supported use case.

Making these limits visible is important. A product should not imply that it can bypass access controls, and users should understand that downloading publicly accessible media does not transfer copyright or permission to reuse it.

FromInsta.net is an independent service and is not affiliated with Instagram or Meta.

Becoming an installable web app

As the interface matured, FromInsta.net also became installable as a Progressive Web App.

This was a natural extension of the mobile-first workflow. People who use the service regularly can open it from their home screen without treating it like a traditional application download.

The goal was not to imitate a native app for its own sake. It was to make a frequently repeated web task quicker to access.

What we learned

The biggest lesson from building FromInsta.net is that a narrow product can still have considerable depth.

A service with one main input field may need to handle multiple content types, asynchronous operations, multilingual layouts, mobile constraints, accessibility, external platform changes, and clear privacy boundaries.

A few principles guided the project:

Keep the primary workflow obvious.
Let users preview results before downloading.
Treat loading and error states as part of the product.
Design localization into the interface.
Be explicit about limitations.
Add features only when they reduce real user friction.
Remember that reliability work is product work.

FromInsta.net still begins with the same simple action: paste a public Instagram link.

Everything added since then has been built around making the next step clearer, safer, and more useful.

Try FromInsta.net