Zero-byte files, HTML stubs, and real completions
A download is finished only when the file on disk matches the expected size and actually plays. Browser UI that says “complete” can still leave zero-byte placeholders or HTML error stubs named like videos. Filenames lie; byte counts and playback tell the truth.
This guide covers the checks after Vidzilla’s Download file step: what a real completion looks like, how to recognize empty and HTML saves, what partials from closed tabs look like, and when to Analyze again because a prepare token expired while you were hunting for the folder.
Download again from the video downloader
What a real completion looks like
Three signals should agree. The browser download entry shows finished status. The file size on disk is in the same ballpark as the megabytes printed on the format row you chose. A local player opens picture and sound when you open that file from disk—not from a remote streaming preview.
Trust disagreement. If the row said roughly 80 MB and disk shows 12 KB, you do not have the video, regardless of a .mp4 or .webm filename. If the size looks right but the middle of the timeline is black or the player stops early, you may have a truncated partial. Either way, do not archive or delete the browser job until the checks pass.
Zero-byte and near-empty files
Zero-byte files appear when a transfer never received payload bytes: cancelled jobs, blocked pop-up downloads, permission prompts dismissed too quickly, or a download that never started because the browser waited for a confirmation you missed. Near-empty files under a few kilobytes often mean the same failure with a tiny header or error body written.
Delete the bad file so you do not confuse it with a later good save of the same name. Return to Vidzilla, keep the tab open, and start Download file again while the prepared asset is still valid. Waiting hours to “try the same button” after the prepare timer expires forces a fresh Analyze even when the URL was fine.
HTML stubs disguised as videos
Sometimes the server returns an HTML error, login page, or interstitial and the browser still saves it with a media-like name. Opening the file in a text editor—or simply noticing that the size is tiny—reveals markup instead of media. Players then say the file is corrupt. That message is accurate for video decoding, but the root cause is a wrong payload, not a mysterious codec curse.
Do not waste time on “repair MP4” utilities when the first bytes are HTML. Fix the URL or access issue if Analyze should not have offered the row, or retry the transfer cleanly if Analyze was fine and the save step grabbed the wrong body. Confirmation exists to catch this class before you move the stub into a library folder.
- File size far below the row estimate
- Player errors immediately on open
- Begins with markup when inspected as text
- Created even though the signed-out page was blocked or gone
Partial media from closing early
Closing the Vidzilla tab, sleeping the machine, or losing network mid-transfer can truncate the file. Partials may be tens of megabytes yet fail when you scrub past the downloaded portion. A claimed twelve-minute video that ends at ninety seconds is incomplete even if the start looks perfect.
Compare duration if your player reports it. Compare size to the row. Re-download the same row without interrupting the browser job. Resuming arbitrary partials from browser download managers is unreliable for prepared media URLs; a full fresh transfer is usually faster than hoping a resume finishes cleanly.
Duplicate names in Downloads
Browsers often append (1) or (2) when a filename collides. Confirm you are opening the newest complete file, not an older zero-byte sibling with a similar name. Rename keepers immediately after a successful check so the next save cannot collide.
A short verification ritual
Before you click Download file, note the megabyte label on the row. After the browser finishes, compare disk size. Play the start. Scrub to the middle. Check audio. Only then rename and move the keeper out of Downloads into a folder you trust.
On phones, open the file from the system Files app (or the browser’s download tray → Open), not only from an in-browser preview that might still stream remote content. You want proof the bytes are local. On desktop, prefer opening from Finder or File Explorer rather than assuming the download shelf thumbnail is authoritative.
When the prepare step expired mid-check
If verification fails and retrying Download file errors because the prepared file expired, run Analyze again, reselect the row, and download in one sitting. Verification should happen immediately after the save, not hours later when you finally find the folder and the temporary media URL is gone.
Free daily limits make failed saves painful. Confirmation discipline protects those slots: one careful download with a size-and-playback check beats three rushed attempts that leave stubs on disk.
Honest edge cases after a good save
A complete file can still look wrong on an ancient player that lacks the codec. Try a modern browser-based player or a current OS media app before assuming truncation. Container labels and true codecs sometimes differ—still, size parity with the row remains your first filter, and a second player is your second.
Vidzilla cannot confirm rights. Playback success does not equal permission to redistribute. Confirm the file finished; then follow copyright and platform terms for how you use the local copy.
Frequently asked questions
The browser said complete—why check size?
Browsers mark the HTTP transfer done even when the body was an error page or a truncated stream. Size compared to the format row and local playback catch that mismatch.
How close should the size match?
Expect the same order of magnitude as the row. A few percent variance can occur; kilobytes versus megabytes cannot. Treat huge gaps as failed saves.
What should I do with a zero-byte file?
Delete it, return to the tool with the tab left open, and download the row again promptly before the prepared file expires.
Can I repair a truncated MP4?
Re-downloading the full row is safer and usually faster than repair utilities on a partial browser save. Fresh bytes beat hopeful fixes.
Does a stub mean Analyze failed?
Not necessarily. Analyze may have listed formats correctly while the browser save step retrieved the wrong payload or was interrupted. Check size and contents before blaming the format list.
Where do browsers put the file?
Desktop browsers default to the Downloads folder unless you chose another path. Phones use the Files app locations tied to the browser or the system download tray.