How to generate a privacy policy for your app or website

Walk through your product as a new user, then compare the screens with the backend. Registration, password recovery, uploads, checkout, support, and analytics can each introduce a different flow. Include the public landing page as well as the signed-in application. A marketing pixel on one and an error reporter on the other both matter.

Make a short working list with four columns: feature, information, recipient, and purpose. Record uncertainty instead of filling gaps with plausible guesses. If an integration exists only in a demo branch, check whether it reaches production. Our website privacy policy guide explains the broader inventory process.

Inspect dependency manifests, environment variable names, deployment settings, network requests, and webhook handlers. These reveal categories such as authentication, database storage, email delivery, payments, diagnostics, and model APIs. A package name alone does not prove a service is active; follow its caller and check the deployed configuration.

Keep credentials, connection strings, personal records, and customer messages out of your notes and any agent conversation. You need the provider's identity and the processing purpose, not its API key. For each active service, establish what it receives and whether you use optional features such as request logging. Mark missing retention information for investigation before you approve the wording.

Open the Privacy Policy Generator for disclosures about personal information. Choose the product type that matches the service: a website, application, store, or hosted software product. Terms of Service are a separate document about using and purchasing the service; choosing privacy does not generate both.

Answer from the inventory rather than selecting every available feature. More clauses do not automatically make a document more accurate. For a hosted product with workspaces and subscriptions, continue with generating a SaaS privacy policy. If a question reveals that the team has no deletion process, decide what you will implement before representing that process to users.

A generator cannot determine your intended audience, actual retention period, or who answers privacy requests from a product name. Those are operator decisions. Ask the person responsible, inspect the system, or change the feature so the answer becomes clear. Do not choose a convenient answer merely because the questionnaire asks for one.

For example, deleting an account row may leave uploads and support records intact. A claim that everything disappears immediately would then be misleading. Trace a disposable test account through creation and deletion, checking every connected system. Avoid using real customer records for this exercise. Your resulting explanation should describe the operation you can perform repeatedly, including justified exceptions.

Read the generated preview from beginning to end. Check the operator identity, product name, public contact details, data categories, purposes, provider references, regional sections, and retention explanation. Compare each substantive statement with something in your inventory. If a clause surprises you, inspect the selected answer rather than accepting it because the prose sounds professional.

The policy contents checklist can help you organize this review. Generated wording is not legal advice or a compliance guarantee. For a high-risk product, a professional review may be appropriate. Keep responsibility for factual accuracy with someone who understands the shipped app, rather than assigning it entirely to a coding assistant.

The questionnaire and preview are available without an account. Simple documents can be downloaded as HTML or PDF without a generation charge; advanced choices can change the price. Read the amount shown for your actual answers before purchasing. Optional hosted publication and subscriptions have their own access rules. The current pricing section explains the available paths.

Choose standalone HTML if you want a complete page you host yourself. A supported HTML fragment fits a page that already has your navigation and visual style. A hosted document gives you a public link without building a legal route. PDF is useful as a companion download, but a readable HTML page is usually easier to link throughout an app.

Use a stable address and verify it in a private browser window. It should display the actual document, without an account, expiring preview token, or development-server dependency. Link it from the footer, registration, checkout, and other relevant collection points. Native apps also need a discoverable in-app route to the document.

Our privacy policy link placement guide covers these locations. Test the link on a phone and with the keyboard, and confirm that the production build contains the latest reviewed version. A successful preview in your local development environment does not demonstrate that a stranger can open the same page after deployment.

Save the factual answers and the approved version with a record of what release they describe. When you add an advertising SDK, AI provider, new sales region, or different retention practice, repeat the inventory and review the affected answers. Do not quietly rewrite an old version in a way that obscures what users were previously told.

Use the update guide to plan reviews around real changes. Assign an owner for checking links and handling requests. A recurring reminder can prompt a review, but it cannot establish that nothing changed. The practical end point is an accurate document connected to working product behavior, not merely a completed generator session.