Privacy Policy.

1. Who is responsible

For processing activities decided by RedFetch itself, the identified responsible party is Marcelo Fabiano / Slonney. The contact channel for privacy questions and data-rights requests is redfetch@proton.me.

This policy describes the code version reviewed on September 26, 2026. Third-party services such as Vercel, Cloudflare, RedGIFs and Proton Mail may also act as independent parties or service providers for the data they process under their own policies.

2. What RedFetch does not do

• does not provide user accounts or its own login system;
• does not ask for credentials to your RedGIFs account;
• does not keep a server-side database of query history; optional Portable history stays only in the tab memory and in the .log file the user chooses to import or export;
• does not integrate Google Analytics, Meta Pixel, advertising, or Vercel Web Analytics in the reviewed code;
• does not use advertising or analytics cookies. localStorage is used only to remember the manually selected language (pt-BR or en-US), and sessionStorage is not used; after a successful anti-bot check, RedFetch also creates the temporary technical session cookie described below;
• does not host a persistent copy of HD/SD video files.

This does not mean that no technical information exists in the infrastructure: hosting and external services process data needed to receive and deliver requests, as explained below.

3. Information processed when you query a link

Submitted URL

Your browser sends the RedGIFs URL you provided to /api/redgifs, together with technical options indicating whether that request needs a preview and/or size check. The backend uses the URL only to validate the domain/path, extract the identifier, and perform the requested query.

RedFetch code does not deliberately write the submitted URL to a database or include it in application logs. It is processed in transit and in the memory required to complete the request.

Anti-bot verification

Before the first query, when there is no valid verification session, RedFetch uses Cloudflare Turnstile to reduce automated API abuse. Turnstile may process technical signals needed for bot detection, such as IP address, User-Agent, TLS characteristics, sitekey and associated origin. RedFetch sends only the verification token to its backend, where it is validated through Cloudflare Siteverify.

After successful validation, RedFetch creates the strictly necessary cookie __Host-redfetch_human. It is server-signed, marked HttpOnly, Secure and SameSite=Lax, and lasts for at most about 2 hours. The cookie does not contain queried URLs, video IDs, query history, email addresses or video content; it only avoids repeating verification for every item, including batch searches.

Connection data and rate limiting

Vercel infrastructure receives requests to the site and its functions. Vercel states that it may process the end user's IP address, approximate location derived from IP, system configuration, traffic data, diagnostics and technical logs. RedFetch application code does not receive precise location.

POST /api/redgifs is also protected by a rate-limit rule configured directly in Vercel infrastructure. The current rule allows up to 150 requests per minute per IP address; when the limit is exceeded, the infrastructure may return HTTP 429 Too Many Requests. The IP address is used technically by the infrastructure to enforce this limit and reduce abuse. RedFetch does not store that IP in its own database for rate limiting; logs and other technical data handled by Vercel follow Vercel's own controls and policies.

Direct contact with RedGIFs

The RedFetch backend communicates with RedGIFs services to obtain a temporary token, public post metadata (such as creator, post date, views and likes when available), file sizes and, when needed, a preview. In Batch mode, the main query does not automatically download every thumbnail: a preview is requested from the backend only when its card approaches the visible area. In Individual mode, the browser may also access the RedGIFs media URL directly to read dimensions/duration and attempt to generate a preview. Opening HD or SD likewise connects your browser directly to the host provided by RedGIFs. In those direct connections, the source service may receive normal connection data such as your IP address and information transmitted by the browser.

4. Preview, size and temporary token

• Preview: the backend may download a RedGIFs thumbnail/poster and convert it to data:image/...;base64 for delivery to the browser. The code does not save that image to persistent storage.
• Size: the backend uses HEAD requests and, when necessary, a one-byte Range request to determine the remote file size. This is not the same as storing the entire video on RedFetch.
• Token: the backend obtains a temporary token from the RedGIFs technical endpoint and keeps it in memory for up to approximately 4 minutes to reduce repeated calls. This token is obtained by the server itself and is not a user-account credential.

GitHub Web compatibility

When “GitHub Web — 25 MiB” is enabled, the comparison runs in the browser using sizes RedFetch has already obtained. This check does not send the video, queried URL, video ID or analysis result to GitHub and does not require a new GitHub integration.

Batch tools

Size summaries, local ID/creator search, filters, sorting, the custom limit, HD/SD savings indicator and Presentation mode are calculated in browser memory from results already obtained; they do not create an account or server-side history. The copy button places only the URLs of displayed results on the clipboard, in their current order. Export creates a TXT file in the browser containing only the results displayed at that moment, preserving order and recording the active filter/sort, along with IDs, HD/SD URLs, sizes, duration, status, error messages and, when available, creator, post date, views and likes. Downloaded files and copied text are then under the control of your device and any apps you choose to share them with. Retrying failed queries makes new calls to the RedFetch endpoint only for those items.

Language preference

When you manually choose Portuguese or English, RedFetch stores only that preference in localStorage under a technical key belonging to the site. The value contains no URL, video ID, history, email address or queried content and is used only to keep your chosen language on future visits. If no preference is saved, the first visit uses the language reported by the browser (navigator.languages/navigator.language) to choose between pt-BR and en-US.

Portable history

Portable history is optional and uses a .log file selected by the user. On import, JavaScript reads the file locally in the browser and the .log file itself is not sent to the RedFetch backend, Vercel, RedGIFs or any other service by this feature. Loaded records remain only in tab memory; RedFetch does not save them in localStorage, sessionStorage or a database. Reloading or closing the page removes this state from memory unless the user exports a new .log file to the device. For compatibility, the importer also accepts .txt files containing valid RedFetch history.

History may contain video IDs, first and last query dates, query count, last status, HD/SD availability, an optional snapshot of public metadata received during the query (creator, post date, views and likes), technical family/revision metadata for the file itself (such as creation time and v1, v2, v3) and, if the user chooses, a history name and description. These optional fields are also processed locally and remain inside the .log file; this feature does not send them to the backend. History records RedFetch queries and does not prove that a file was downloaded. If the user chooses to query a history ID again, the corresponding URL/ID returns to the normal query flow described in this policy; enabling “Skip previously queried IDs” prevents that new request for recognized items. Restoring IDs from history to the Batch queue also happens only in browser memory and makes no request until the user starts a search. Removing known IDs from the queue or hiding previously queried cards changes only the local/visual state of the current operation and does not erase or modify history records.

5. Logs and retention

Application code records only minimal information about failures in external services — error type and HTTP status when available — without deliberately logging the queried URL, video ID or request body.

Vercel maintains its own infrastructure logs and telemetry. Retention periods vary by plan and enabled products. In documentation reviewed in September 2026, standard Runtime Logs were retained for about 1 hour on Hobby, 1 day on Pro and 3 days on Enterprise, with longer retention available through additional products. Vercel may change these limits.

Emails sent to redfetch@proton.me are subject to Proton Mail storage and policies until deleted or for as long as needed to address the request or comply with a legal obligation.

6. Purposes and legal bases

When information can be considered personal data, RedFetch seeks to limit processing to what is necessary to:

• perform the query requested by the user and deliver the result;
• maintain security, prevent abuse and diagnose failures proportionately;
• respond to contacts, complaints and rights-related requests;
• comply with legal or regulatory obligations and valid orders when applicable.

Depending on the situation, these purposes may rely on legal bases under Article 7 of Brazil's LGPD, such as performing the requested service, a legitimate interest compatible with the data subject's rights, or compliance with a legal obligation. RedFetch does not use “generic consent” as a blanket justification for processing.

7. Sharing and third parties

RedFetch does not sell personal data to advertisers and the reviewed code contains no advertising network.

8. Your rights

Where RedFetch acts as controller of your personal data, you may request, as applicable, confirmation of processing, access, correction, anonymization, blocking or deletion of unnecessary or improperly processed data, information about sharing, objection and the other rights provided by Article 18 of the LGPD.

Because RedFetch does not keep a server-side query-history database, in many cases there will be no persistent record of the searched URL in the project's database to locate or delete. You may still request clarification about technical processing or email messages you sent.

9. Security

The project uses technical measures proportionate to its size, including HTTPS provided by the host, domain/path validation in both frontend and backend, no user credentials, server-side Cloudflare Turnstile validation, a short-lived signed technical session, short caching of the temporary RedGIFs token, security headers, a restrictive referrer policy, minimized application logs and the ability to block specific identifiers in RedFetch when necessary.

No internet-connected system is absolutely invulnerable. If you identify a security issue, send details to redfetch@proton.me and avoid accessing third-party data beyond what is necessary to demonstrate the issue.

10. Children and teenagers

RedFetch is not directed to children or teenagers. Because the tool may display previews and links to third-party adult content, there is a relevant regulatory obligation to prevent improper access by minors. Current Brazilian law does not treat a simple self-declaration of age as a sufficiently reliable mechanism for this type of access.

As of September 22, 2026, Brazil's ANPD still indicated that final guidance on scope and age assurance was being consolidated. The responsible party will monitor those rules and may modify, restrict or suspend features as necessary. This policy does not claim that publishing legal text alone makes the service fully compliant with the ECA Digital.

11. Changes and contact

This policy may change if the code, providers, infrastructure or applicable law changes. The revision date will remain shown at the top.

Sources and references