Privacy Policy

This policy applies to zyff.app: every tool page, the API endpoints behind those tools, and widgets you build here and embed on your own site. It describes what the software actually does, not a generic template, and it is written to be read rather than skimmed past.

Two facts shape everything below. First, every Zyff tool works without an account, so for tool use we hold no username, password or profile. An account is needed for one thing only — embedding a widget on your own website, which also lets you edit it afterwards — and what it stores is set out under “Accounts” below. Second, Zyff's tools run on our servers rather than in your browser, so files do reach us for the length of a request. What happens to them in that window is the subject of the next section.

This is a general privacy policy for a general-audience utility site. It is not legal advice, and it does not cover your own obligations if you publish a Zyff widget on a site you operate.

Uploads are processed in memory on Zyff's servers and are not stored. Your browser sends the file over HTTPS to an API endpoint, the server decodes it, applies the settings you chose, and returns the finished bytes in the response. The upload exists only as a buffer for the life of that single request, then it is gone with the request.

Nothing is written to disk, queued, or copied into a database, object store or backup. There is no gallery of past jobs, no history, and no link that lets anyone retrieve a file later, because there is no file to retrieve. Results come back with a no-store cache header, and your browser assembles the download from the response it already holds.

Uploads are never used to train or improve a model. The background remover runs a pre-trained open-source segmentation model on our own servers using weights stored with the application, so your image is not sent to a third-party AI service. That model finds the outline of a subject; it does not identify people, and no face template is created or kept.

Several tools also reduce what your files carry outward. The compressor and resizer bake in EXIF orientation and then drop embedded metadata, so GPS coordinates, camera serial numbers and capture timestamps do not survive into the output. The converter keeps metadata only if you explicitly turn that option on.

Because no tool asks you to sign up, whole categories of data never enter the picture for ordinary tool use: no email address, no password, no phone number. If you create an optional account, we receive your email address and name from Google — nothing more. If you subscribe to a paid plan, payment is handled entirely by Razorpay; your card details go to them and never touch Zyff's servers, so we could not store them even by accident.

Zyff also runs no advertising. There are no ad networks, no conversion pixels, no retargeting tags and no data brokers. We do not sell, rent or share personal information for advertising. The site does measure what you do with a tool — see the analytics section below, which names what it records — but nothing on Zyff builds a marketing profile of you or follows you to another website.

Zyff runs a handful of measurement tools, and it is more honest to name each of them than to claim the site has no analytics. Vercel Web Analytics counts page views and records the referring source, approximate country and device type. Vercel Speed Insights records real-world loading and interaction timings, such as how long a tool page takes to become usable, tied to the route rather than to a person. Neither of those two uses a cookie.

Google Analytics 4 does. It is the tool that answers what actually happens on a tool page, and it works by recording named events as you use one: a tool page was opened, a file was accepted or rejected and why, a setting was changed, a conversion started, finished in so many milliseconds or failed with a particular message, a result was downloaded or copied. Each event carries the shape of what you did — the file's type and size in kilobytes, the output format, how long the server took — so that we can tell a tool nobody finds from a tool that breaks.

What it never carries is the content. Your file name is not sent, because a file name is routinely someone's name, a client's name or an invoice number. Nor is the image, the clipboard, the generated snippet, or the name of a business you looked up in the reviews builder. The event says "a 2.4 MB JPEG was compressed to WebP in 900 ms", never which JPEG.

To tell a returning visitor from a new one, Google Analytics writes two first-party cookies in your browser — _ga and one named after this property, _ga_<id> — holding a random identifier it generated. They expire two years after your most recent visit, and clearing site data removes them. If you sign in to a Zyff account, we also send Google the opaque account identifier, a random UUID and never your email address or name, so that using two of your own devices is not counted as two different people.

We do not enable Google Signals, we do not link the property to Google Ads or any other advertising product, and we build no advertising audiences. If that ever changes, this page changes with it in the same release.

Alongside those, the page loads Google Tag Manager. Tag Manager measures nothing itself — it is a container that lets us add or remove a measurement script without shipping new code, and the events described above are handed to it rather than being collected twice. Loading it means your browser requests a script from googletagmanager.com, so Google receives your IP address, your browser and device type, and the page you are on, exactly as it already does for the Analytics script served from the same place. It sets no cookie of its own.

Because a container is configured outside this codebase, the honest commitment is about what we will put in it: measurement only. No advertising tag, no conversion pixel, no retargeting or cross-site tracker, and nothing that receives a file name, a file's contents or a business you searched for — the same limits that apply to Analytics. Anything added to it that collects something new is named on this page in the same release.

The result is behavioural, and calling it merely aggregate would be a stretch: individual event streams exist inside Google Analytics for a period, and we read them to find where a tool loses people. What we cannot do is connect any of it to a file, a business search or a named individual, because none of that is ever sent.

All of them are ordinary scripts loaded after the page is usable, so common content blockers and privacy-focused browsers stop them. Blocking any of them has no effect on the tools — a reasonable test of whether analytics is load-bearing here. Google Analytics does not act on a Do Not Track or Global Privacy Control header, so if you rely on those, blocking the script is the thing that works.

There is a chat bubble in the corner of every page. It is operated for us by Brevo (Sendinblue SAS, France) using their Conversations product, and it is there so a question about a tool can be answered without you having to open an email client. Talking to it is entirely optional, and every tool works whether or not you ever click it.

The chat script is loaded on every page once the browser is idle, so Brevo sees that a page was opened even if you never open the chat: the URL, the referring page, your IP address, and your browser and device type. If you do start a conversation, Brevo receives and stores what you type, anything you attach, and whatever contact details you volunteer so we can reply — normally an email address. Do not paste anything into the chat that you would not put in an email, and do not attach a file you would not want stored: unlike a tool upload, which is processed in memory and never kept, a chat attachment sits in a support inbox.

To keep a conversation attached to you as you move between pages and come back later, Brevo sets its own first-party cookies and browser storage holding a random visitor identifier it generated. That identifier is used to thread your messages, not to profile you, and clearing site data removes it. We do not send Brevo your file names, your uploads, or anything you did with a tool; if a conversation record contains something about a file, it is because you typed it.

Transcripts are held in Brevo's inbox for as long as they are useful for support and any follow-up. Like the analytics scripts, this one is an ordinary third-party script that a content blocker or a private window will stop — the only thing you lose is the chat itself. If you would rather not use it at all, ashokguptaa66@gmail.com reaches the same people.

Zyff is hosted on Vercel, so every request passes through their infrastructure. Standard request data such as your IP address, user agent, the URL requested, the timestamp and the response status is processed there in order to route traffic, keep the site available, and detect abuse or attacks. This is normal operational processing that any hosted website performs.

Zyff's own application code keeps no record of who uploaded what. When a request fails unexpectedly, the code writes an error entry so the failure can be diagnosed; that entry contains the error, not the contents of your file. We do not use log data for marketing, profiling or ad targeting.

Log retention is limited to what our hosting provider keeps for operational and security purposes. All traffic is served over HTTPS, the Google Places key is held only in server environment variables, and every API endpoint validates input server-side rather than trusting what the page sent. No system is completely secure, but the design deliberately minimizes what exists to lose: there is no store of user files to breach.

The Google Reviews builder involves third-party services by design, and it uses two. When you search for a business, the text you type and the place you select are sent from our server to the Google Places API, which is what turns what you typed into a specific business. Our API key stays server-side and is never placed in the page, so the request comes from Zyff rather than from your browser.

The reviews themselves are then collected through Apify, a hosted data-collection service, which reads the business's public Google Maps listing — the same page anyone can open without signing in. We use it rather than the Places API because that API returns at most five reviews per request with no way to ask for others, and a widget that can only ever show five is not much use to a business with hundreds. Our Apify token also stays server-side. If the collection cannot run for any reason, Zyff falls back to the Places API and the widget shows the five reviews that API returns.

What comes back is the business name, address, rating, review count, a Google Maps link, business photos, and the reviews themselves — each with the reviewer's display name, profile picture, a link to their Google profile, a link to the review, and the review text. Up to 200 reviews are collected when you ask for them, against five from the Places API fallback. That content originates from Google and belongs to the people who wrote it. We render it and let you restyle it, but we do not alter the words. Because a published widget has to keep working, that content — including those reviewers' names, pictures and words — is stored in the cache described below rather than only passing through. We also keep what earlier collections returned, so the set only grows: indefinitely, up to 200 per business. We collect a business again only when someone using the widget builder presses a button; nothing runs on a timer. Two consequences follow, and we would rather state them plainly than bury them: a review that has since been deleted on Google stays in our copy until a later collection replaces it, and there is no timer that removes it on its own. If you are a reviewer and want a review removed, remove it at Google first — then email ashokguptaa66@gmail.com naming the business, and we will delete our stored copy for it.

Business photos, reviewer profile pictures and any photos attached to a review are loaded by your visitor's browser directly from Google's own image servers, exactly as any other Google-hosted image would be. Where a business was connected before this collection method existed, its photos are still requested through /api/tools/google-reviews/photo: Google's media endpoint requires the API key as a query parameter, so pointing an image tag at it directly would publish the key, and instead our route performs the keyed lookup server-side and redirects your browser to the keyless address Google returns.

To avoid paying Google for identical lookups, resolved business details are cached. Search suggestions are held in server memory for 5 minutes and are lost when the process ends. Resolved businesses are held in a database table for 20 hours, and may be served for up to 30 days beyond that if Google becomes unreachable — so that a widget already embedded on your site keeps working rather than going blank. That table is keyed by the Google place id, holds only what Google returned about a public business, and records nothing about who searched for it. It is what an embedded widget reads, which is why it has to outlive a single server process. The keyless image address that Google's photo endpoint returns for a business photo is cached the same way for 1 day, so repeat views of one photo do not repeat the lookup; that address identifies a photo of a public business, never a person.

Google's and Apify's own terms and privacy policies govern what each does with these requests. If you publish the resulting widget, the embed loads a script from zyff.app and requests the stored review data when your page renders, which means visitors to your site send requests to Zyff's servers and to Google's image servers. Describe that in your own site's privacy notice.

For a widget saved to an account, the embed script also reports each render back to Zyff, because plans include a monthly view allowance. What is kept from that report is a running total per account per calendar month — a single number. No page URL, no cookie and no identifier of the visitor is stored with it; the visitor's IP address is used transiently for rate limiting, as on every endpoint, and does not enter the count.

The Instagram Feed and Facebook Reviews widgets work like the Google Reviews widget, with one difference worth naming: neither Instagram nor Facebook offers an API that returns a public account's posts or a page's recommendations without a business app and a review process. Zyff therefore collects that public content through Apify, a hosted data-collection service. Our Apify token stays server-side and is never placed in the page, so the request comes from Zyff rather than from your browser.

What comes back is what those pages already show the public. For Instagram: each post's image or video, its caption, its like and comment counts, its date, its address on Instagram, and the username that posted it — plus, for an account source, that account's profile picture, biography and follower, following and post counts. For Facebook: each recommendation's text, its date, whether it recommends the page, the reviewer's display name and profile picture, a link to the recommendation, and the page's own name, picture and totals. That content originates with the people who wrote and posted it, and we do not alter their words.

Because a published widget has to keep working, that content is stored rather than only passing through. An Instagram feed stays fresh for 2 days before Zyff will re-check it, and may be served for up to 30 days beyond that if a refresh fails — so a widget already on your site keeps working rather than going blank. A Facebook page uses 3 days and 30 days. Because each collection returns only a recent window, we also keep what earlier collections returned: up to 120 posts per feed and 100 recommendations per page. We keep them indefinitely and re-check only when someone using the builder asks us to — nothing runs on a timer. The same two consequences follow as for Google reviews, and we would rather state them plainly than bury them: a post or recommendation that has since been deleted stays in our copy until a refresh replaces it, and there is no timer that removes it on its own. If something of yours appears in one of these widgets and you want it removed, delete it at the source first, then email ashokguptaa66@gmail.com naming the account or page, and we will delete our stored copy.

Instagram and Facebook images are requested through Zyff rather than loaded directly from their servers. Their image addresses carry a signature and an expiry — measured at under five days — so an image tag pointing at one would break on your site within about a week of you embedding it. Our route fetches the image server-side and passes it through, cached for 1 day. That means the request for a widget image comes from Zyff and not from your visitor's browser, so Instagram and Facebook do not see your visitors. These tables are keyed by the account, hashtag, location or page, and record nothing about who looked one up.

Apify's own terms and privacy policy govern what Apify does with these requests. If you publish one of these widgets, the embed loads a script from zyff.app and requests the stored content when your page renders, which means visitors to your site send requests to Zyff's servers. Describe that in your own site's privacy notice.

Every tool works without an account. Signing in exists for one reason: embeddable widgets. Building and previewing one needs no account; getting its embed code does, because a widget that renders on your website has to belong to an account — that is what lets its monthly views be counted against a plan, and what lets you edit it afterwards so every site embedding it updates without re-pasting the code.

Sign-in is delegated to Google. Zyff never sees or stores a password. From Google we receive your email address, your name and your profile picture URL — nothing else, and no access to your Google account beyond identifying you. Authentication is operated by Supabase on our behalf, and a session cookie keeps you signed in between pages.

The account record itself is deliberately thin: an identifier, your display name and avatar URL, which plan you are on, and the widgets you have saved. Your email address is held by the authentication service rather than copied into our own tables, so deleting the account removes the identity outright rather than leaving a stray copy behind.

You can delete your account yourself from the account page. That removes your identity, your saved widgets, and — because the widget is what the embed code points at — every widget you saved stops rendering on the sites where it is embedded. That is stated here in those words because it is the consequence people are least likely to expect.

Zyff's paid plans are optional subscriptions that affect saved widgets only. No tool is behind any of them.

Payments are processed by Razorpay. Your card or bank details are entered on Razorpay's own checkout and go directly to them — they never pass through, and are never stored by, Zyff's servers. What we keep is the identifier Razorpay gives the subscription, which plan and currency it is on, its status, and when the current period ends. That is what tells the site whether your plan is active; it is not enough to charge you, and we could not do so independently.

If you cancel, your subscription runs to the end of the period you have already paid for and is not renewed. If you delete your account, the payment record is detached from your identity and kept only as long as tax and accounting law requires.

Zyff writes one value to your browser's localStorage: a key named zyff-theme holding either light or dark. It is set only when you use the theme toggle, and a small inline script reads it before the page paints so your chosen theme is applied without a flash of the wrong colors.

This is local state, not tracking. It is not a cookie, it is never sent to our server, it contains no identifier, and no other website can read it. Clearing site data for zyff.app removes it, and the site then falls back to whatever light or dark preference your operating system reports.

Zyff sets cookies for three purposes. The two Google Analytics cookies described above hold a random identifier so a returning visit is not counted as a new one. The Brevo Conversations chat widget sets its own, holding a random visitor identifier so a conversation follows you between pages. And if you sign in, Supabase sets a session cookie so you stay signed in between pages — it is strictly necessary for the account to work, it is set only after you choose to sign in, and signing out removes it. Google Tag Manager, described in the analytics section, sets none of its own. There are no advertising cookies, and no cookie on this site is used to follow you to another one. The zyff-theme value in localStorage is a preference you set yourself, not a cookie.

The Analytics, Tag Manager and chat scripts are loaded for everyone, without asking first. That is worth stating plainly rather than burying: if you would rather they did not run, a content blocker or a private window stops them, and every tool works exactly the same either way.

Beyond those, the page loads little from anywhere else. Web fonts are self-hosted: the three typefaces Zyff uses are downloaded at build time and served from zyff.app, so loading a page makes no request to Google's font servers. There are no embedded videos and no social buttons.

That leaves a short and complete list of companies that can receive data as a result of your visit:

For visitors in the EEA, the UK and Switzerland, the GDPR and UK GDPR require us to identify a legal basis for each purpose. Ours are straightforward:

Retention follows from the design. Uploaded files are not retained at all. Account data and saved widgets are kept until you delete the account, which you can do yourself at any time. A record of a subscription payment is retained after account deletion, detached from your identity, for as long as tax and accounting law requires. Email you send us, and any chat conversation you start, are kept only as long as needed to handle your request and any follow-up. Analytics events are held by the provider for their standard measurement window — Google Analytics keeps event-level data for a limited retention period set on the property, after which only aggregated reporting remains. Operational logs are kept by our hosting provider for a limited period for security and troubleshooting.

Zyff is hosted on Vercel, whose infrastructure processes requests in the United States and other countries. Google may process Places API requests, and sign-in, in the United States and other countries. Supabase hosts the account database, Razorpay processes payments from India, Apify processes the Google, Instagram and Facebook collection requests from the Czech Republic, and Brevo operates the chat widget from the European Union. Where a transfer safeguard is required for data leaving the EEA or the UK, we rely on the mechanisms our providers make available, such as standard contractual clauses and applicable transfer frameworks.

If you are in the EEA, the UK or Switzerland, you have the right to access your personal data, to have it corrected or erased, to restrict or object to processing, to data portability, to withdraw consent where consent is the basis, and to lodge a complaint with your supervisory authority (in the UK, the Information Commissioner's Office).

If you are a California resident, the CCPA as amended by the CPRA gives you the right to know the categories and specific pieces of personal information collected, to delete it, to correct it, to opt out of its sale or sharing for cross-context behavioral advertising, to limit the use of sensitive personal information, and not to be discriminated against for exercising any of these rights. You may use an authorized agent. Zyff does not sell or share personal information, does not collect sensitive personal information, and offers no financial incentives for data, so those particular opt-outs have nothing to act on. If that ever changes, this page will change with it and a mechanism will be added.

If you have never created an account, there is an honest limitation worth stating plainly: because tools need no account and uploads are not stored, we usually hold no record tied to you and therefore nothing to produce, correct or delete. What can realistically be acted on is any email correspondence or chat conversation you have sent us, and request-level data held by our providers where it can be traced to you. If you DO have an account, you can delete it from your account page; that removes your identity, your saved widgets and your subscription's link to you.

In the twelve months before the date at the top of this page, the categories involved have been internet and network activity (pages viewed, referring source, approximate country, device and browser type, and the tool interactions described in the analytics section), device and connection identifiers such as IP address, user agent and the random Google Analytics and chat-widget cookie identifiers, and the contents of any email you chose to send us or message you chose to type into the chat. Nothing else.

To exercise a right, email ashokguptaa66@gmail.com and describe what you want. We aim to respond within 30 days, and within the 45 days the CCPA allows, extendable by a further 45 days where the request is complex. We may ask for information needed to confirm the request relates to you, and we will not use that information for anything else.

Zyff is a general-audience utility site and is not directed to children. We do not knowingly collect personal information from children under 13, or from anyone under 16 in the EEA and the UK. No tool asks for any personal information, and there is no advertising to target. Accounts are optional and require a Google sign-in; if we learn that an account belongs to a child below these ages we will delete it.

If you are a parent or guardian and you believe a child has sent us personal information, most likely by emailing us, write to ashokguptaa66@gmail.com and we will delete it.

When this policy changes, the updated version is posted on this page and the effective date at the top is revised. Material changes will be summarized here rather than slipped in quietly. We do not run a mailing list, so the effective date is the record of when the terms of this policy last moved.

Privacy questions, data requests, security reports and anything else go to the same inbox: ashokguptaa66@gmail.com. Include enough detail that we can act on it without a round trip.