This page describes a reproducible method for checking the downloader. A method is not a live uptime report, and it does not establish that every media type or browser is currently working.
On this page
What counts as a successful download?
A useful test goes beyond seeing a green success message. The result must refer to the submitted post, the advertised media option must be accurate, and the saved file must open with the expected content. Video checks include picture, sound and duration; photo checks include image count and order.
An HTTP 200 response or a visible button alone is not proof of a working download. A cached result also needs a working final media address.
Which cases belong in a test run?
| Case | Evidence to record |
|---|---|
| Owned or permitted public video | Correct video, watermark state, duration and audio |
| Short link to the same post | Equivalent media after resolving the link |
| Audio-capable post | Actual audio encoding and whether the track matches |
| Photo or slideshow post | Image count, ordering and save behavior |
| Invalid or unavailable link | Clear error without a fabricated result |
| Expired result session | Fresh-link recovery or an understandable expiry message |
| Story, profile or Douyin | Separate evidence for that conditional feature |
How should browser behavior be checked?
Repeat the main workflow on representative mobile and desktop browsers. Record the browser version and operating system. Check manual paste as well as permitted clipboard access, keyboard navigation, narrow screens and the final file location.
A desktop layout check does not establish that a physical iPhone successfully saved a file. Each test record should say exactly what was tested.
What makes a test record credible?
Record the date and time zone, permitted sample identifier, media type, browser and device, expected outcome, observed outcome and any failure. Redact private details and temporary media tokens before sharing evidence.
No dated production test log or measured success-rate dataset is published on this page. Do not interpret the method, a screenshot or an automatic page-update date as a reliability percentage. See troubleshooting for current user checks, or report a reproducible failure.
What do automated checks establish?
Local fixtures can check page rendering, internal links, language-pack structure and media classification without downloading another person’s content. Browser simulations can test FAQ controls and contact-form success and failure states. These checks identify regressions in the code paths they exercise.
A simulated response is not proof that a live provider can retrieve a current post. Production checks must save permitted sample files and inspect them. Email validation must also distinguish acceptance by WordPress from actual receipt in the mailbox. Records should state that scope instead of presenting a combined universal success rate.