Guide · measured October 2026

Uploading to TikTok without compression

We uploaded three clips to TikTok with one field in their header changed, then downloaded what TikTok served back. All three were identical to what we sent, down to the last byte. The same footage uploaded without that change came back at 576p. Here is the test, and what it does not tell you.

The short answer

On three clips out of three, TikTok returned the uploaded file byte for byte — same size, same md5 hash. Not re-encoded at a gentler setting; not re-encoded at all. The only change made to those files was the movie-level duration in the MP4 header, written as “unknown”.

The same video and audio uploaded without that change came back at 576 × 1024 and 30 fps, keeping between 10 and 24 percent of their bitrate.

That is three clips, all 1080p at 60 fps, on one account over two days. It depends on TikTok tolerating a field it cannot read, so it could stop working. What it does not establish and what would break it are below. If you want to try it on your own video, the encoder makes exactly this one change and nothing else.

What came back

Each clip was uploaded twice: once untreated, once with the duration field changed. Within each pair the video and audio were byte-identical — only the MP4 container around them differed.

All three sources were 1080 × 1920 at 60 fps. “Identical” means the whole file, not just the resolution. Here is each treated upload against what TikTok served for it:

4.6 s    11,136,662 bytes
  sent   5871b3b9a43840e9ffae5ff2fe1829c7
  back   5871b3b9a43840e9ffae5ff2fe1829c7

18.1 s   40,015,188 bytes
  sent   45134ba89ebbdff468a0910cdae4d714
  back   45134ba89ebbdff468a0910cdae4d714

23.2 s   54,357,147 bytes
  sent   c0ea2791c49803b1aa1fdfa5593928e8
  back   c0ea2791c49803b1aa1fdfa5593928e8

A matching md5 means the same bytes, in the same order. TikTok stored the file and served it as it was — no re-encode, and not even a repackaging of the container.

An earlier test showed that the treated file kept its resolution. That left open whether TikTok was compressing it more gently or not compressing it at all. Comparing hashes settles it: for these three, not at all.

How it was measured

1. Build both versions from one source. Each pair came from one export, so the video and audio bitstreams were the same and only the container differed. That was checked with a per-stream md5 before uploading — without it, the experiment measures nothing.
2. Upload them the same way, close together. Same account, same route (tiktok.com, from a computer), minutes apart.
3. Let processing settle. A reading taken minutes after posting is not final — one video gave different numbers shortly after posting than it did an hour later.
4. Download what TikTok serves, and measure that. Resolution is read with ffprobe from the served file, and its hash compared with the upload’s. Resolution alone hides the interesting part, which is whether anything was re-encoded at all.

One field does all the work

To produce the treated file, the encoder rebuilds the whole container: it moves the header to the front, re-lays the boxes, and rewrites the duration. So one obvious question is whether the rebuild does anything on its own. For the first clip, two more variants were uploaded alongside the pair:

The rebuild with a correct duration was treated exactly like the untouched original, down to the size of the file TikTok served. Rebuilding the container contributes nothing. Neither does stripping an editor’s metadata, which we tested separately. The duration field is the whole effect.

One more thing that was ruled out: tiktok.com applies “HD by default” to uploads from the web, and it cannot be switched off. All four variants went up with it on, and two still came back at 576p — so it is not what saved the treated file.

TikTok does read that field

The 10-hour variant was not quietly processed. The web uploader refused it:

{
  "status_code": 3013036,
  "status_msg": "Can't upload more than 60 minutes"
}

So the movie duration is parsed and acted on. A duration TikTok can read and dislikes gets the upload refused. A duration it cannot read is accepted, and the file comes back untouched.

Our reading is that an unreadable duration leaves the pipeline with nothing to base a transcode decision on, so the file passes through as it is. That is inference. We can see what went in and what came out, never what happened in between.

How much an untreated upload loses

All three untreated uploads were cut to 576p and 30 fps, every time. How much bitrate survived varied: 24, 10 and 18 percent. That did not follow the clip’s length — the 18-second clip fared worse than the 23-second one — so it most likely depends on the content, which is something we cannot measure from outside.

In short: the loss was reliable without being predictable. Three clips do not support a formula, and we are not offering one.

What this does not establish

• Other kinds of source. Every clip was 1080p at 60 fps. Nothing here says how a 30 fps or sub-1080p upload is treated. That is the obvious next test.
• Other accounts and regions. One account, over two days. Account-level or regional differences in how TikTok handles uploads are not ruled out.
• Other routes in. These went up through tiktok.com from a computer. We have also posted one of the treated files through a third-party tool that uses TikTok’s direct-posting API, and it came back byte for byte too. We have not hashed a phone-app upload, and the apps compress large files on the device before sending them — more on that here. Our own posting page loses the effect entirely, because the post is finished inside the TikTok app, which re-encodes it. That page says so.
• Every copy TikTok keeps. We hashed the file TikTok served to us. If it keeps other versions for other devices or connections, we have not looked for them.
• Why some posts keep 1080p. This answers what keeps your own upload intact. It does not answer why some other people’s videos stay 1080p and others drop to 576p — eleven posts whose uploads we cannot see. That question is still open, and that guide says so.

What would break it

This works because TikTok tolerates a duration it cannot read. It is a quirk, not a feature, and TikTok can change it without telling anyone.

The 10-hour refusal shows TikTok already validates this field. If it starts treating “unknown” as invalid too, treated uploads would most likely start failing — refused with an error, not quietly degraded. That is a total failure, but at least a visible one. If it happens, upload your original export instead: the encoder never changes the picture, so the original is the same video.

The other possibility is quieter: TikTok could start ignoring the field and re-encode treated files like any other. Nothing would be refused, and the only sign would be a softer result. So it is worth running the post through the quality checker once it is live. The badge on the home page also shows when this was last confirmed against a real upload.

Trying it on your own video

The encoder makes exactly the change tested here and nothing else. Every frame of video and every sample of audio is copied across byte for byte, in your browser, without the file being uploaded anywhere. If TikTok stops honouring the trick, you have lost nothing compared with uploading the original.

For the closest match to these results, we recommend finishing the edit before you start, uploading on tiktok.com from a computer, and checking the result afterwards. The steps on the home page cover phones too.

Prepare a video