{
  "id": 18249318,
  "title": "How I Check a Download Is a Real MP4, Not an HTML Error Page Wearing a .mp4 Name",
  "url": "https://urgent.news/2026/11/05/how-i-check-a-download-is-a-real-mp4-not-an-html-error-page-wearing-a",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-11-05T04:49:31.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/mobeenahmedgondal/how-i-check-a-download-is-a-real-mp4-not-an-html-error-page-wearing-a-mp4-name-1m9f"
  },
  "original_language": "en",
  "account": "A download link can be misleading, and I discovered that fact the hard way while creating ramrom.io, my own video downloader. Sometimes, a server would send a 200 status code, a filename with a .mp4 extension, and a body that turned out to be an HTML error page. Visitors would save the file, only to learn upon trying to play it that it was not a video at all. The file extension does not guarantee its content, and the status code is not entirely reliable. So, before I sent the file to a visitor, I implemented a series of checks to verify the file's actual nature. These steps are executed in the following order:\n\n1. Trust no headers alone. The first check is the Content-Type header, but only as a hint. A genuine MP4 usually arrives with the video/mp4 content type, while an error page typically arrives with text/html. Although rare, there might be instances where a provider sends an HTML error with a video/mp4 header, and a more common scenario is a provider sending a video file with an application/octet-stream header.\n\n2. Scan the initial bytes before sending anything to the visitor. This is the crucial check. Every MP4 file begins with a box structure; within the first four to seven bytes, you will find the letters \"ftyp.\" The first four bytes indicate the box size, followed by \"ftyp,\" then a brand name like isom or mp42. In contrast, an HTML page starts with something such as \"!DOCTYPE\" or \"html.\" My proxy reads the first chunk of the response into a buffer before sending any headers to the visitor. If those bytes represent HTML, I stop, discard the chunk, and display an honest error message, such as \"the file could not be fetched.\" If the bytes indicate \"ftyp,\" I proceed. Reading those initial bytes before sending headers prevents any potential problems once the headers have been sent, as changing them would result in the visitor receiving an incomplete file.\n\n3. Perform a sanity-check on the size. Real videos are rarely a few hundred bytes in size. If the Content-Length header indicates a file size of just 412 bytes, but the file claims to be a video, it raises suspicions. In such cases, I dismiss the file entirely, even if the magic bytes appear correct. Similarly, if the header promises a ten-megabyte file and the connection abruptly closes after fifty kilobytes, it suggests a truncated file rather than a complete download. Therefore, I refuse the file in such scenarios.\n\n4. Examine the tail only when it is efficient. A full MP4 file also contains a moov box, which holds timing and index data. However, searching for this information means reading the entire file, which defeats the purpose of streaming it directly. On shared hosting with limited memory, such extensive parsing is not feasible. Thus, I do not parse the entire file. While the ftyp check and size check can catch real-world failures such as error pages, login walls, and expired links that return a deceptive HTML page instead of a file, I do not delve into the entire file's contents.\n\n5. Communicate the issue clearly. The final step is not technical but rather a matter of communicating the problem to the visitor. When a check fails, the visitor encounters a message like \"the provider returned an error page instead of a video\" instead of an endless spinner or a broken file. An honest error message is beneficial, not embarrassing. None of these checks are particularly clever; they are merely four small checks implemented in plain PHP without any additional libraries. Reading the header, scanning the first bytes, verifying the size, and failing gracefully when something does not align are sufficient to ensure that visitors receive a trustworthy tool rather than a deceptive one. The filename serves as a promise, and verifying the file's contents is how I uphold that promise.",
  "summary": "A download link can lie. I learned that the hard way while building ramrom.io, my little video downloader. A provider would return a 200 status, a filename ending in .mp4, and a body that was actually an HTML error page. The visitor's browser would save it happily, and only when they tried to play it would they find out it was not a video at all. The extension means nothing. The status code means…",
  "key_points": [
    "Verify Content-Type header as a hint, not sole confirmation",
    "Scan initial bytes for \"ftyp\" to confirm MP4 format",
    "Check file size against Content-Length header for sanity"
  ],
  "editors_take": "Verifying file headers and sizes before delivery transforms a deceptive download process into a reliable service by preventing users from saving error pages disguised as valid video files.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}