What happens to your link after you press Download
Between the paste and the saved file there are four distinct stages. Knowing them explains most error messages you will ever see here.
Downloader sites tend to describe themselves in adjectives: fast, safe, unlimited. The more useful description is mechanical. Here is the sequence SaveNova actually runs, in the order it runs it, with the point at which each common error can occur.
Stage 1 — The link is parsed, not fetched
Before any external request, the pasted text is checked as a URL: a supported scheme, a hostname on the platform allowlist, a path that identifies a public media item, and a length within the server’s bound. Share tracking parameters such as igsh, si, sender_device, mibextid, and utm_* are removed, leaving the canonical permalink.
This stage is pure validation. A hand-written string cannot make the server contact an arbitrary address, which is why private network addresses and look-alike domains are rejected here rather than later. It is also why “unsupported platform” and “invalid URL” arrive instantly, while a real retrieval takes seconds.
| Message | What it means |
|---|---|
| Invalid URL | The text is not a complete http(s) link |
| Unsupported platform | The domain is not one of the five supported hosts |
| Unsupported content path | The domain is supported, but the path is a profile, feed, or other non-media page |
| URL too long | The input exceeds the server’s length limit |
Stage 2 — The public media is retrieved
The server asks the platform for the public post and works out which media files are actually published. For most platforms this uses a hardened extraction pipeline with bounded timeouts, an allowlist of media hosts, and a size ceiling; for image and carousel posts a platform-specific collector can supply the assets. Redirects are followed only within validated rules, and the resolved addresses are checked so a redirect cannot turn into a request to an internal service.
Nothing here signs in, solves a challenge, or reuses a cookie. When the platform refuses an anonymous request — YouTube’s bot check is the most familiar example — this stage returns a failure with a message, and the later stages never run.
Stage 3 — Options are described from observation
What you see in the options panel is generated from the retrieved metadata: container, resolution, carousel index, and watermark status where one can be verified. Assets the platform returns once are listed once. A “Without Watermark” entry appears only when a separate clean asset exists, as explained in what the label means.
The download buttons do not point at a raw platform CDN URL. They point at SaveNova’s own endpoints with a signed, time-bound ticket that encodes the validated target. That keeps the media URL validation and SSRF checks in force for the actual file transfer, not just for the page lookup.
Stage 4 — The file moves to your browser
Pressing a download button starts a transfer from SaveNova to your browser. On capable browsers, the response is written into origin-private temporary storage so the page can show progress and offer a local preview; the finished snapshot is then handed to the browser’s normal download mechanism. Browsers without that storage, or with a full quota, fall back to a direct browser download with no in-page progress. The progress and files guide covers where the file ends up on each phone platform.
What is not stored
- No account, no history. There is no sign-in and no per-user record of the links you submit.
- No URL database. Submitted URLs are processed to serve the request; they are not collected into a searchable archive.
- No credentials or cookies. The tool never asks for a platform login and does not accept one.
- No secret CDN URLs in the page. Options carry internal tickets, and the ticket is what the download route validates.
Standard server facts still apply and are described in the Privacy Policy: infrastructure processes ordinary request metadata for security and rate limiting, and optional analytics and advertising are gated behind the consent choices described there.
Why request IDs are worth keeping
When a request fails, the error message includes a reference ID, and the same ID appears in the server’s sanitised diagnostic line for that request. If you report a problem through the contact page, that ID is more useful than a screenshot of the error: it ties your report to the exact attempt without exposing the media URL.
The practical limits of the pipeline
- Popularity help, not guarantees. Public posts change, expire, and move between CDNs. A link that worked yesterday can fail today.
- Heavy requests are queued. Extraction jobs are limited per process, and a busy server returns a retryable “busy” message instead of silently slowing to a halt.
- Size ceilings exist. A configurable per-file ceiling and available server resources bound what can be staged, and an oversized request fails with a clear message rather than a truncated file.
- Regions differ. Platforms serve different results by geography, and SaveNova cannot choose the region its server appears in.
How this guide was checked: written by the SaveNova team and reviewed on 1 November 2026 against the behaviour of the current build, including the limitations described above. It contains no invented test results or performance figures. If a step no longer matches what you see, report the guide and we will correct it.