Privacy Policy Generator

Shipping an app means shipping two documents: a privacy policy and a terms of service. The hard part is not finding one to copy, it is that the copy rarely matches your product. App store reviewers compare what you say you collect, the permissions the app actually requests, and the SDKs bundled into it; one mismatch gets the submission sent back, sometimes with a deadline to fix it. This tool starts from the facts instead: choose what you collect, which services you use, how you charge and whether users can delete their data, and the text is written from those choices. Change one checkbox and the document is rewritten.

How to generate one

• Two documents, one profile: switch between privacy policy and terms of service at the top; product name, legal entity, contact details and effective date are shared, while each document expands its own clauses
• Collection scope becomes clauses: tick categories such as device information, logs, location, camera, microphone, contacts, storage, clipboard, sensors and payment details, and each one becomes a clause describing what is collected and why, with the matching system permission. Unticked categories never appear, which keeps you from over-declaring
• Three collection stances: local only (collect nothing), essential data only, or collected and shared with third parties. With the first option the text states plainly that no permissions are requested and nothing is uploaded, a sentence that utility apps often forget
• Third-party capability list: push, analytics, ads, payments, maps, social login, support chat, cloud storage, sharing and crash reporting can be ticked separately, and SDK names entered as a comma-separated list get their own paragraph so the document matches the store disclosure list
• Storage and cookies: choose domestic storage or cross-border transfer, with the latter spelling out security assessment and standard contract filing; cookies and localStorage each get their own clause
• Your rights and deletion channels: access, correction, deletion, withdrawal of consent, obtaining a copy and objecting to automated decisions are listed, with deletion handled through in-app self service, email request or no account needed, each with its own process and response time
• Minors: choose general audience or possible users under 14; the latter adds guardian consent and a promise to delete children's data
• Terms of service cover fees and liability: fully free, one-time purchase, auto-renewing subscription and ad-supported each get their own billing and cancellation wording, with refunds chosen separately; liability is capped at the amount paid in the last 12 months, while responsibilities that cannot be excluded by law are preserved
• Optional clauses: real-name accounts, user content and licensing, AI-generated content, usage limits and fair use, export control, and notices; add or remove them without leaving empty headings
• Missing fields are visible: required values left blank become placeholders in the text and are listed below the form, and they stay in exported files so nobody mistakes the document for complete

When to use it

• A solo developer submitting to the App Store, Android stores or HarmonyOS for the first time and needing a complete policy
• A purely local utility that wants to state accurately that it collects nothing and requests no permissions
• Filling in the explanation text required for a mini program privacy guideline
• Updating the third-party section after adding an analytics or push SDK
• Pasting an existing policy to check for missing clauses on deletion, cross-border storage or minors
• Producing plain text for a store console, Markdown for a repository README and HTML for a website in one pass

FAQ

• Can I submit the generated text directly? The structure and wording follow current regulations and common store review points, so it works as a draft, but you must check every clause against what you actually do. It is a template, it cannot promise something your product does not do, and it is not legal advice. For sensitive data, cross-border transfer, paid subscriptions or regulated fields such as health, finance and education, have a professional review it
• Do the two documents need to be separate? Yes. The policy answers how you handle data; the terms answer whether and how the service may be used and who is responsible when something goes wrong. Most stores want two pages or two links, which is why the tool keeps them apart
• Why the emphasis on the SDK list? Reviewers compare your declared SDKs with a static scan of the package. Listing one you do not use, or using one you did not list, gets the app rejected, so the field is its own section and stays free-form
• How should a local-only tool be written? Set the overall collection stance to collect nothing. The text then states that nothing is collected, uploaded or requested, while keeping contact details and policy update clauses, which holds up better than a template that declares a dozen data categories
• What are the effective and updated dates for? Both appear in the header and in the update clause. Changing the content without changing the date leaves no way to prove which version came first, a common reason for rejection
• Is the form data uploaded? No. Values live only in the current page memory, the document is assembled in the browser, copy and download use a local Blob, and no request is made; refreshing clears everything
• What else does a store need? Usually a permission usage dialog, a third-party sharing table and an SDK inventory. Align those with the text word for word, and settle the choices here before editing the other materials rather than the other way around