Free app privacy policy generator for Android & iOS

What this tool does

This generator turns your answers into two documents that Google Play expects every app with user data to have: a privacy policy and a page that explains how a user can delete their account and data. Both are written in plain English, structured with the headings reviewers and users look for, and ready to paste into a web page.

Everything happens in your browser. The form is processed by code that runs on your own device, so the app name, email address and data choices you enter are never uploaded, logged or stored by us. Close the tab and they are gone.

How to use it, step by step

• Fill in the basics. Use the developer name exactly as it appears on your Google Play listing. Reviewers compare the two.
• Be honest about data. Tick everything the app collects, including what your libraries collect for you. Analytics and ad SDKs usually collect device identifiers even if your own code never touches them.
• List your third-party services. Each one you tick is added to the policy with a link to its own privacy policy, which is what Google asks you to disclose.
• Answer the children and deletion questions. These two sections are where reviews most often fail.
• Switch between the two tabs, check the preview, then copy or download. Put the policy and the deletion page on public web pages you control and paste both links into the Play Console.

What Google Play requires in a privacy policy

Google Play requires every app that handles personal or sensitive user data to link a privacy policy in the store listing and to show it inside the app. The policy must be on an active, publicly reachable web page (not a PDF and not behind a login), and it must name the developer and give a way to contact them.

The policy has to disclose how your app accesses, collects, uses and shares personal and sensitive data, and to whom. Anything you declare in the Play Console Data safety section must match what the policy says. A mismatch between the form and the policy is one of the most common reasons an update is rejected.

Apps that let people create an account must also offer a way to request deletion of that account and its data, both inside the app and through a web link you submit in the Play Console. That is why this tool writes a separate delete-account page rather than leaving it as one paragraph at the bottom of the policy.

What a good policy contains

• Who you are and how to reach you. A real developer name and a working email address.
• What you collect. A specific list, not "information you provide". If the app collects nothing, say so plainly.
• Why you collect it. One purpose per data type. Collecting something with no stated purpose is a red flag.
• Who you share it with. Name each third-party service and link to its policy.
• How long you keep it and how a user deletes it. Include a number of days, not "as long as necessary".
• Children. A clear statement of whether the app is aimed at under-13s and what you do about it.
• User rights and changes. How a user can ask for access or correction, and how you announce updates to the policy.

Common mistakes that cause rejections

• Forgetting SDK data. Firebase, AdMob and analytics libraries collect identifiers. If your Data safety form lists them but your policy does not, the two disagree.
• Copying another app's policy. It will mention features and data you do not have, and it will leave out the ones you do.
• Hosting the policy as a PDF, on a page that needs a login, or on a link that returns an error.
• Saying the app is not for children while the content, design or category clearly attracts them.
• Offering deletion only by "contact support" with no email address, or no deletion path at all for an app with accounts.
• Never updating the policy after adding a new SDK or permission.

A short example

Suppose a small study app signs users in with email, stores progress in a database, measures usage with analytics and shows banner ads. You would tick Email address, Account info and Device identifiers, then Firebase Authentication, Cloud Firestore, Firebase Analytics and Google AdMob, answer No for children, choose deletion inside the app and by email, and enter 30 days for retention.

The generated policy then lists those three data types with a reason each, links the four services to their own policies, states that the app is not directed at children, explains the deletion route, and promises removal within 30 days. The delete-account page repeats the same steps in a form a reviewer can follow in a minute.

Before you publish

A generated policy is a starting point. Read every sentence and remove or change anything that is not true for your app. If you collect health data, serve children, process payments yourself, or operate in a regulated sector, ask a lawyer to review the result. Keep the effective date current and update the policy whenever you add a library, a permission or a new use of data. When the policy is live, work through our Google Play launch checklist to confirm the rest of your listing is ready, and read how we build and publish apps on our Android development page.