TikTok Video Size Limit.

It is three different numbers, not one. Uploading from the iOS app the practical ceiling is around 287 megabytes, from the Android app it is around 72, and from tiktok.com it runs into gigabytes. TikTok does not publish per-app file sizes on its own help pages, so those two app figures are widely reported rather than official and the table below says so. What is published is the length: a video recorded inside the app runs up to ten minutes, and TikTok Studio's own uploader asks for MP4 or WebM under ten gigabytes. The practical advice is simple. If a file will not go from your phone, upload the same file from a browser instead, and if it still will not go, compress it rather than cutting it, because TikTok is going to re-encode it anyway.

Almost always one of five things, and the report names which. Size is the common one and it is rarely the number you expect: TikTok's iOS app stops around 287 megabytes and its Android app around 72, while the website takes ten gigabytes of the same footage, and Discord's ten megabytes is a free-account limit rather than a Discord limit. Length is next, and it is per surface rather than per platform, so a sixty second cap on a story sits next to a three minute cap on a Short. Then container and codec, which is what refuses a WebM or an AVI at a door that only opens for MP4 and H.264. Then the shape, where a landscape clip simply is not a Short. Then colour, where an HDR recording is either refused or quietly flattened. Drop the file here and the row that is red tells you which one it was, and the link next to it opens the bench that changes it.

Bitrate times length, and nothing else. A file's size is its bitrate multiplied by its duration, so a minute of 4K at 100 megabits weighs about 750 megabytes no matter what you do to the container. The report prints the overall bitrate next to the picture and sound bitrates so you can see where the weight sits: a 60 megabit picture with 128 kilobit sound is a picture problem, and no amount of touching the audio will help. Phone footage is heavy for a reason worth knowing, which is that phones encode in real time and spend bitrate rather than time; re-encoding the same footage properly often halves it with no visible difference. That is what the compressor does, and the size row here links straight to it with the right ceiling already selected.

HDR is a different rule for turning stored numbers into light. An SDR file uses the BT.709 curve every screen has assumed for thirty years; an HDR10 file uses PQ, and HLG uses a third curve again, both on the wider BT.2020 primaries. A player that reads a PQ file as though it were BT.709 shows you a flat, grey, low-contrast picture, which is exactly what happens when a platform strips the colour tags during a re-encode, or when an editor imports the file without recognising them. The report names the transfer and the primaries and says HDR10, HLG, Dolby Vision, or SDR in plain words, so you know before you upload whether you are handing a platform something it is going to mishandle. If it is, converting to SDR yourself, where you can see the result, beats letting an uploader do it out of sight.

Every row carries the date it was last checked and a link to the page it was checked against, and the table footer says the most recent of those dates. That is deliberate, because these numbers move constantly and most of the pages you will find quoting them carry no date at all. Where a platform publishes a number on its own help page, the row is marked verified and links to it. Where the figure is real but only reported second hand, which is most app-specific file size ceilings, the row says reported. Where a platform publishes nothing at all, which is the case for iMessage and for Signal, the row says unverified and you should treat it as a hint. The limits live in one editable file in the repository, and anything wrong in it is a bug worth telling us about.