Video & subtitles · Direct Media Downloader
What 'the URL is checked before anything is contacted' actually means
· How it works
urls privacy security
Explains the checks a browser can run on a pasted link without sending a single packet, and why the Direct Media Downloader runs them before it announces the host it is about to contact.
Pasting a link is not the same as opening it — the difference between reading a string and making a request
Pasting text into the field does not open it. The input listener trims and parses the characters, updates a help line, and enables or disables controls without calling Fetch, DNS, or any ToolAcre endpoint. A URL can therefore be examined while the Network panel remains unchanged.
That distinction is the first privacy boundary. The page can say that a string is structurally usable before exposing it to the named host. A request starts only after an explicit Check link or Download action, and those actions have different HTTP methods and outcomes. Because no remote fact exists yet, a reviewer can reproduce this stage with offline tests and confirm that every accepted or refused result depends only on supplied characters.
Parsing with the URL API: scheme, host, path and query — what the browser can tell about a link offline
The URL constructor separates protocol, credentials, hostname, port, path, query, and fragment on the device. ToolAcre then normalises the hostname for comparison, including case and a trailing dot. This is syntax work over a string, not evidence that the destination exists or answers.
Pasted wrapping quotes or angle brackets can be removed, a scheme-less public hostname can gain HTTPS, and known analytics parameters can be dropped. Signed parameters such as tokens, expiry values, signatures, and X-Amz fields are deliberately preserved because changing them could change authorization or make the link fail. Ports remain part of the parsed address even though the announcement uses the hostname, so an unusual explicit port should still be inspected in the full normalized URL.
Rejecting unsafe destinations, not guessing whether a public URL is a file
The shipped validator does not reject a public watch page merely because its path lacks a media extension. Instead it rejects empty or malformed input, every scheme except HTTPS, embedded usernames or passwords, internal names, private address ranges, loopback, link-local, multicast, and several obfuscated IPv4 and IPv6 spellings.
A successful local verdict consequently means “safe enough for this browser tool to contact,” not “confirmed direct media.” The later HEAD check may reveal HTML through Content-Type, and the interface warns then. Keeping those claims separate prevents a plausible path ending in .mp4 from being treated as proof of bytes. This sequencing also avoids maintaining a brittle extension allowlist that would reject legitimate extensionless object routes while accepting any misleading path decorated with a familiar suffix.
Showing the host before contacting it — how the announced host is derived from the parsed URL, not from a response
For an accepted address, the help line names the normalized hostname and says that nothing has been contacted yet. That host comes from the parsed URL supplied by the visitor; it is not learned from a response, lookup, redirect, embedded player, or page scraper.
This preview also makes disguised credentials visible as a refusal rather than trusting the text before an at-sign. The announcement covers the initial destination only. If that server later redirects the request, browser developer tools are needed to see the final address and every intervening hop. The full normalized address remains visible in the field, allowing the visitor to compare scheme, port, path, and sensitive query material before choosing whether contact is appropriate.
Worked example: three pasted strings and the limits of each verdict
Consider `https://media.example/clip.mp4`, `example.com`, and a public watch-page URL. The first passes the safety checks and names media.example. The bare domain is normalized to HTTPS and can also pass, while the page address may remain structurally acceptable because path semantics are not inferred locally.
That third result corrects a tempting overclaim in the brief: URL parsing cannot prove that a page is a file. Pressing Check link sends a credential-free HEAD request; a `text/html` response triggers a “may not be media” warning. Even `video/mp4` remains a server statement rather than content inspection. A bare public domain is therefore not falsely certified as media, and a platform page is not advertised as rejected until remote evidence actually supports that narrower conclusion.
Why no DNS lookup or preflight happens during the check — the check runs on the string alone; the network is untouched until the fetch is announced and made
No DNS query, CORS preflight, HEAD, GET, or proxy call belongs to `validateMediaUrl`. Its implementation is pure and reads no DOM or network global. This allows private-address and scheme cases to be tested exhaustively without creating traffic toward the strings used as fixtures.
The boundary moves when the visitor presses a network button. Check link sends HEAD with redirects followed, caching disabled, credentials omitted, and referrer suppressed. Download sends a similarly configured GET. A host can then fail through CORS, transport, HTTP status, expiry, or authentication requirements. This split lets a security test prove “typing is quiet” independently from network tests that exercise HEAD, GET, redirects, response headers, and cancellation.
What this does not cover — the check cannot know whether a file exists, whether you are allowed to fetch it, or whether the server will redirect
Local validation cannot establish existence, ownership, licence, response type, file size, server behavior, or redirect destination. It also does not resolve a hostname first and compare every returned address. The tool’s private-host checks are defence in depth, not a guarantee about future DNS answers.
Permission remains the visitor’s responsibility. The checkbox records a statement that the media is owned or authorized; it is not legal verification. Links behind login remain unreachable because requests omit cookies and credentials, and no validation result unlocks DRM, a paywall, or another access control. When a hostname can later resolve differently, destination governance belongs with the host operator and browser network stack as well as this initial syntactic and literal-address screen.
Takeaway: check first, announce, then fetch — how this order is what lets you trust the tool's network promise
The reliable order is parse, apply safety policy, show the initial host, and wait. Only a deliberate button press produces traffic. This makes the quiet phase observable: clear DevTools, type several strings, and confirm that the request list stays empty while verdicts change.
Use Direct Media Downloader for a permitted direct HTTPS file address, then treat Check link as a separate remote probe rather than an extension of parsing. The design earns trust by attaching a narrow claim to each stage instead of pretending one green message has verified the internet. That evidence chain is deliberately modest: it proves order and declared controls without claiming that local parsing can predict a remote system or authorize its content.