Who is responsible
Not yet published: the operator/controller identity and public contact details have not yet been configured. This is a separate legal-completeness gap from whether the site is technically indexable by search engines, and remains open until an operator identity and contact are published here. No identity or address is implied by the NSFWDL brand name.
The sensitive input you provide
When you submit a URL, NSFWDL receives that complete URL in a small POST request. Adult-content URLs can be sensitive: their paths or query strings may name content, performers, accounts, or access tokens, and a person's use of one could permit sensitive inferences. NSFWDL uses the URL to validate the public destination, choose an extraction route, request the source page, and deliver the media you select. It does not treat the URL as evidence of your identity, sex life, sexual orientation, or preferences, and does not build an interest profile from it.
The downloader does not put the submitted URL in an NSFWDL page query string, title, canonical URL, or public result URL. Smart routing temporarily uses browser session storage to move the URL between NSFWDL downloader pages, consumes it on arrival, and rejects records older than about two minutes.
Short-lived extraction state
Extraction necessarily produces a source URL, media/CDN URL, title, format identifiers, request headers, thumbnail reference, and sometimes uploader, tag, category, or similar source metadata. The application keeps the sensitive values in bounded process memory behind random opaque references. The configured default lifetime is 15 minutes, records may be evicted earlier when capacity is reached, and all in-memory state disappears on process restart. A public extraction response can show the title and a same-origin thumbnail, but it does not expose the submitted page URL, upstream media URL, signed tokens, cookies, or extracted tags.
Media delivery and temporary files
A direct media response is streamed through NSFWDL and is not saved as a complete media file. A format that requires preparation, merging, or remuxing is written to a private temporary directory with an opaque name. Prepared files are removed after a successful full transfer, preparation failure or timeout, job expiry, or orderly process shutdown. A partial or ranged transfer may leave the file available for resume until its job expires. The configured job lifetime is one hour; a conservative startup cleanup also removes clearly stale job directories older than the configured stale threshold, currently six hours. Unexpected termination or an operational fault can therefore extend a temporary file's presence beyond the normal one-hour job lifetime. NSFWDL is not a permanent media archive.
Server, network, and security data
A web request inherently exposes network data such as IP address, timestamp, requested NSFWDL path, browser headers, and transfer size to the server and any network, hosting, reverse-proxy, DNS, or security provider involved. The application does not read or add the visitor IP address to its own event logs, and its Uvicorn access log is disabled. That does not prove that every infrastructure layer keeps no access or security log; the final providers and their retention settings must be verified before launch.
Application logs use coarse fields such as source family, extraction engine, success or failure category, latency, format class, size bucket, queue lane, and opaque job ID. The logging code deliberately excludes submitted URLs, titles, performer or uploader names, tags, signed media URLs, cookies, supporter keys, and session tokens. These operational events support service health, abuse prevention, debugging, and resource planning. Current code has no user-level adult browsing-history table.
Requests to third-party sources
To perform the request, NSFWDL sends the submitted public URL to the original source platform through server-side extraction tools. It may then request media or thumbnails from that source or its delivery hosts. Those third parties receive NSFWDL's server network address and ordinary request headers, and apply their own terms and privacy practices. The separate dl.nsfwdl.com delivery hostname is configured as another entry point to the same application; its opaque download URL does not contain the source URL.
NSFWDL does not ask users to upload account cookies. A source-specific cookie file may be configured privately on the server for permitted public-page compatibility. It is not user-provided or exposed publicly, and it must never be used to bypass subscriptions, private pages, or paywalls.
When a real thumbnail image is unavailable, some results can instead offer an optional inline video preview. The preview never loads automatically and never plays audio or video on page load. If you press play, your browser requests the video directly from the source's own media host, not through NSFWDL's server, so that host receives your IP address and browser information for that request in the same way it would if you visited the source page directly. NSFWDL does not store, cache, or log anything about a preview play.
Supporter data
Free use requires no account. Supporter access uses a random activation key and an HTTP-only session cookie. The SQLite store contains hashes of the key and session token, internal random identifiers, creation/expiry/revocation times, and an optional short operator note. The downloader application does not contain a donor identity or payment-account table. If a user follows an external donation link, that provider receives data under its own policy; NSFWDL should not place a submitted adult URL or extracted-media metadata in such a link.
Cookies and browser storage
The secure-by-default, HTTP-only, SameSite=Lax Supporter session cookie is set after a valid key is activated. The smart router uses session storage briefly as described above. A local-storage entry records only an accepted/rejected analytics choice. If, and only if, a visitor accepts optional analytics, Google Analytics 4 sets its own first-party measurement cookies. No advertising, remarketing, or third-party tracking script beyond Google Analytics is present. See Cookies, Analytics & Advertising for the full current inventory.
Analytics, advertising, and affiliate links
Google Analytics 4 is active, optional, and consent-first: before an explicit choice and whenever a visitor rejects, no Google tag is requested and no request reaches Google at all. Only after explicit acceptance is the tag loaded and configured. This is not GA4's cookieless "consent mode" measurement while denied — nothing is requested from Google before acceptance. Advertising consent signals (ad_storage, ad_user_data, ad_personalization) stay denied regardless of the analytics choice, and Google Signals and ad-personalization signals are explicitly disabled; NSFWDL does not use Google Ads or remarketing. Analytics events are limited to a small fixed set of product actions (extraction/download attempted, succeeded, or failed) and neutral parameters (source platform, device class, a bounded error category); a submitted URL, download filename, title, performer, content tag, or extracted-media metadata is never sent, and the reporting code has no access to those values in the first place. Google Analytics applies its own standard campaign/referrer attribution after consent (for example, recognizing a tagged social-media link); NSFWDL does not separately collect that data, and every page's canonical address, sitemap entry, and search-indexing identity are unaffected by how a visitor arrived.
No advertising provider is currently integrated. Before any third-party network advertising is activated, the provider, data flows, consent behavior, transfers, and retention must be documented. NSFWDL will not sell or disclose submitted adult URLs or extracted-media metadata to advertisers. An external affiliate or ad provider may receive ordinary browser, device, IP, impression, and click data when its link or script is used. Affiliate links must be clearly identified and must not carry the user's submitted source URL or extracted metadata.
Purposes and legal bases
- Provide the service you request: validate, extract, prepare, and deliver a public URL; generally necessary to perform the requested service or take steps at your request (GDPR Article 6(1)(b), where applicable).
- Operate and protect the service: coarse logs, rate and resource controls, security checks, and abuse prevention; pursued as legitimate operational and security interests (Article 6(1)(f)), balanced against the unusually sensitive context.
- Meet legal duties and handle claims: process valid privacy, safety, legal, or copyright requests (Article 6(1)(c) where a duty applies, or legitimate interests in establishing and defending legal claims).
- Optional analytics or advertising storage: consent where required (Article 6(1)(a) and applicable ePrivacy rules). Consent can be refused or withdrawn without losing the core downloader.
A submitted adult URL could, in context, reveal special-category information under GDPR Article 9. NSFWDL minimizes and transiently processes such input only on the user's instruction and does not infer or profile it. The operator must obtain jurisdiction-specific advice on the applicable Article 9 condition before public launch; Article 6 alone does not resolve that question.
Retention and minimization
The application lifetimes above are code-backed defaults, not claims about every infrastructure system. Operational and security logs are kept only as long as operationally necessary, but the final infrastructure providers and exact log retention periods have not been verified for launch. Supporter key and session records remain until expiry/revocation and operational cleanup; exact database retention also requires an operator decision. Legal correspondence may need to be retained while a request or claim is handled and for applicable limitation periods. Final retention periods and deletion procedures must be documented before launch rather than invented here.
Security
NSFWDL uses opaque references, private runtime directories, bounded request and process limits, no-store and no-referrer response headers, SSRF protections, restricted media types, hashed supporter secrets, and short-lived state. No internet service can promise absolute security. Report a suspected exposure through the safety contact route.
Your data-protection rights
Depending on applicable law, you may request access, correction, deletion, restriction, portability, or information about processing, and may object to processing based on legitimate interests. You may withdraw consent at any time without affecting earlier lawful processing. Because NSFWDL deliberately avoids accounts and long-term URL history, it may hold too little information to identify a record as yours; the operator may request limited verification and will not collect extra sensitive information merely to create a match.
You may also lodge a complaint with the data-protection supervisory authority where you live, work, or believe an infringement occurred. The operator's establishment and lead authority are unresolved pre-launch facts and will be identified before public launch.
International transfers and processors
The final hosting, network, analytics, payment-link, advertising, and support providers are not all selected or verified. Some may process data outside the EEA. Before activation, NSFWDL must identify each relevant provider, role, location, transfer mechanism, safeguards, and retention terms. This staging policy does not claim safeguards that have not yet been configured.
Adults only
NSFWDL is intended only for people aged 18 or older who can lawfully use an adult-content service. It is not directed to children and does not knowingly seek their personal data. Any suspected child sexual abuse material or exploitation must be reported through the urgent safety route and may be reported to competent authorities as required by law.
Policy changes
This page will be updated when data flows or providers change. Material changes—especially analytics, advertising, identity, transfers, or retention—must be published before the new processing begins and new consent obtained where required. The version date above identifies this text; it does not invent a launch date.