Video File Info.

Drop it here. The report reads the container's own headers and prints the codec family with its profile and level, the coded and displayed resolution, the aspect, the rotation flag, the measured frame rate, the bitrate, the colour tags, and every track the file carries. On a desktop you can get some of this from the file properties panel, but properties panels tell you the resolution and stop: they will not tell you that the codec is H.264 High 4.1 rather than Baseline, that the frame rate is variable rather than 30, that the index sits after the media, or that the transfer curve is PQ. Those are the four facts that actually explain a failed upload or a file that will not import, and they are what this page is for.

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.